> 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.
--
/dev/rtc symlink not pointing at /dev/rtcN
https://bugs.launchpad.net/bugs/252924
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
