Comment 14 for bug 252924

> We would want to make sure that /dev/rtc pointed to the same real time clock after each reboot

The /dev/rtc0 node is stable because the 2.6.27-7 kernel has CONFIG_RTC_DRV_CMOS=y and all others set =m. Thus, rtc-cmos.c is always initialized before any other rtc-*.c module, and it creates only one device using the CMOS_ macros, which reliably becomes /dev/rtc0 on any normal i386 or amd64 computer.

The old char/rtc.c driver does the same thing, so my guess is that compatibility is maintained, if only for the first device. It seems sensible and reasonable that the kernel developer would do this intentionally.

Furthermore, the 2.6.27-7 kernel has CONFIG_RTC_HCTOSYS_DEVICE="rtc0" , and the __init rtc_hctosys(void) function always uses it at boot time. If /dev/rtc0 is unstable in this configuration, then beta testers would be complaining that the system clock is unexplainably unreliable across reboots, which isn't happening.

A refinement of the proposed udev rule would be

  KERNEL=="rtc0", ATTR{name}=="rtc_cmos", DRIVERS=="rtc_cmos", SYMLINK+="rtc"

so that it catches the corner-case of a customized local kernel with a second static rtc driver. A solution any more fancy would require something like writing a '70-persistent-rtc.rules' file and a patching `/lib/udev/path_id` to recognize the rtc device class.

> That isn't relevant to this bug.
>
> The backwards compatibility has been broken by the kernel.

Not completely broken, as beta testers are reporting that the patch works properly when /dev/rtc0 is backed by the CMOS driver.

> Adding a null0 and null1 is irrelevant, they both have the same major and minor number.

Correct, but you're being ungraciously pedantic with my example. I am trying to explain the regression and motivate a practical fix.

Regular people will think "Ubuntu broke my VMware" if they get the Intrepid upgrade with a missing /dev/rtc.