/dev/rtc symlink not pointing at /dev/rtcN

Hi Jimmy,

Thanks for the report. I've done some additional investigation. It appears that CONFIG_RTC being enabled is dependent on CONFIG_RTC_LIB being disabled. For the Intrepid kernel however, CONFIG_RTC_LIB is in fact enabled:

ogasawara@yoji:~/ubuntu-intrepid/debian/config$ grep -rn "CONFIG_RTC_LIB" *
amd64/config:2251:CONFIG_RTC_LIB=y
i386/config:2397:CONFIG_RTC_LIB=y

I also noticed an interesting comment in the Kconfig regarding CONFIG_RTC:

ogasawara@yoji:~/ubuntu-intrepid/drivers/char$ grep -A7 -B7 "config RTC" Kconfig

#
# These legacy RTC drivers just cause too many conflicts with the generic
# RTC framework ... let's not even try to coexist any more.
#
if RTC_LIB=n

config RTC
 tristate "Enhanced Real Time Clock Support (legacy PC RTC driver)"
 depends on !PPC && !PARISC && !IA64 && !M68K && !SPARC && !FRV \
   && !ARM && !SUPERH && !S390 && !AVR32
 ---help---
   If you say Y here and create a character special file /dev/rtc with
   major number 10 and minor number 135 using mknod ("man mknod"), you
   will get access to the real time clock (or hardware clock) built

As you can see, "These legacy RTC drivers just cause too many conflicts with the generic RTC framework ... let's not even try to coexist any more." I'm guessing that the kernel team won't likely disable CONFIG_RTC_LIB in favor of using legacy drivers, but that's just my thought. I did however also notice something else interesting:

ogasawara@yoji:~/ubuntu-intrepid/debian/config$ grep -rn "CONFIG_RTC_INTF_DEV=" *
amd64/config:2247:CONFIG_RTC_INTF_DEV=y
i386/config:2393:CONFIG_RTC_INTF_DEV=y

ogasawara@yoji:~/ubuntu-intrepid/drivers/rtc$ grep -m1 -A12 "config RTC_INTF_DEV" Kconfig
config RTC_INTF_DEV
 boolean "/dev/rtcN (character devices)"
 default RTC_CLASS
 help
   Say yes here if you want to use your RTCs using the /dev
   interfaces, which "udev" sets up as /dev/rtc0 through
   /dev/rtcN. You may want to set up a symbolic link so one
   of these can be accessed as /dev/rtc, which is a name
   expected by "hwclock" and some other programs.

   This driver can also be built as a module. If so, the module
   will be called rtc-dev.

I'm curious if you create /dev/rtc as a symlink to /dev/rtc0 if this will resolve the warning you are seeing? Let us know. Thanks.

Hi Leann.

You are spot on. As soon as I create the softlink vmware doesn't give the error.
I have confirmed that by removing the softlink again, the error message reappears.

Best regards
Jimmy

Hi Jimmy,

Thanks for the testing and the feedback. It seems this really isn't a bug with the kernel but just new changes being made. I'm going to reassign your bug report to the "udev" package to see if they'll add a symlink rule to create /dev/rtc . Thanks.

When there are multiple rtc devices, which should /dev/rtc point to?

Does the kernel provide any guarantee that /dev/rtc0 and /dev/rtc1 will be the same devices on the next boot, or might they swap?

To have the symlink made automatically I added the following line to /etc/udev/rules.d/60-symlinks.rules

KERNEL=="rtc*", SYMLINK+="rtc"

VMware no longer complains.

Can we please have that patch committed for Intrepid?

I can confirm that the proposed patch works.

The proposed patch is invalid.

Now will someone please answer my questions?

Wondering if this is not a VMWare bug. VMware workstation should search for the proper /dev/rtc*.

Calling this a VMware bug is unfair because:

  * The kernel KConfig for the new driver (at line 93) recommends linking /dev/rtc to the new character device for backwards compatibility, which Intrepid does not do.

  * The legacy /dev/rtc device has not been deprecated in either the Intrepid man page or kernel changelog.

  * The /dev/rtc device has existed for a long time, so people that use it will be surprised that it is missing in Intrepid.

All rtc-dev.c nodes should behave similarly, so the link referent that udev chooses doesn't matter. The problem with the older implementation is that the RTC could be opened only once.

Thus, the missing /dev/rtc is a regression.

If /dev/rtc0 and /dev/rtc1 are identical, why are they different?

Ubuntu Intrepid removes a traditional interface that breaks popular software, so the pertinent issue is backwards compatibility.

Whether /dev/rtc0 and /dev/rtc1 are identical or different is irrelevant to the person using the computer because either would be adequate for software that expects the legacy interface. This is nearly the same as reimplementing /dev/null as /dev/null0 and expecting the userland to go looking for it.

Why is keeping a /dev/rtc link for compatibility the wrong choice?

On Thu, 2008-10-23 at 16:23 +0000, Darik Horn wrote:

> Ubuntu Intrepid removes a traditional interface that breaks popular
> software, so the pertinent issue is backwards compatibility.
>
That isn't relevant to this bug.

The backwards compatibility has been broken by the kernel. If you wish
to argue that this shouldn't have happened, please file a bug on the
kernel and ask for the change there to be reverted.

This bug is filed against the userspace daemon udev, which mixes kernel
information with userspace rules, and creates device nodes accordingly.

The kernel is now asking udev to create rtcN devices, where each rtcN
device appears to be connected to a device on various buses. On my
system, I have a single such device:

  /sys/devices/pnp0/00:04/rtc/rtc0

From the information I have, it would appear that you will *only* get a
second rtcN device (rtc1) if you have a *second* RTC clock in your
computer. You may see something such as:

  /sys/devices/pnp0/00:04/rtc/rtc0
  /sys/devices/pci0000:00/0000:00:0a.0/rtc/rtc1

Where rtc0 is a PnP device and rtc1 is a PCI device.

The information I am asking for is whether this will be consistent, or
whether (as is the case with just about every other kernel enumerated
device) these may change with each reboot.

ie. after rebooting, might you instead have:

  /sys/devices/pnp0/00:04/rtc/rtc1
  /sys/devices/pci0000:00/0000:00:0a.0/rtc/rtc0

Instead.

In that case, /dev/rtc0 in the previous boot is now /dev/rtc1
and /dev/rtc1 in the previous boot is now /dev/rtc0.

So the question I ask, and would like answered are:

 - Are rtcN devices attached to particular items of hardware?

 - Are the enumerations fixed, or after each reboot might they be
   different?

If they are attached to hardware, and are not fixed, then we need to
take more care to create the symlink. We would want to make sure
that /dev/rtc pointed to the same real time clock after each reboot, and
didn't randomly flip-flop between them.

> Whether /dev/rtc0 and /dev/rtc1 are identical or different is irrelevant
> to the person using the computer because either would be adequate for
> software that expects the legacy interface. This is nearly the same as
> reimplementing /dev/null as /dev/null0 and expecting the userland to go
> looking for it.
>
Wrong.

Sorry, but your above rationale shows a serious lack of knowledge about
how devices work.

/dev/null is a kernel-implemented device node: you can have as many
copies of it as you like, with as many different names as you like, but
they all fundamentally terminate at the same code in the kernel
driver.

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

From what I understand, /dev/rtcN are *hardware* device nodes and each
one terminates at a different piece of hardware.

I also understand that each /dev/rtcN has a different major and minor
number (in the open allocation space) - so each one is fundamentally a
different device.

You might as well suggest that you can freely swap /dev/sda1
and /dev/sda2 around and expect things to work.

> Why is keeping a /dev/rtc link for compatibility the wrong choice?
>
What are the percussions of usin...

> 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.

On Fri, 2008-10-24 at 06:10 +0000, Darik Horn wrote:

> A refinement of the proposed udev rule would be
>
> KERNEL=="rtc0", ATTR{name}=="rtc_cmos", DRIVERS=="rtc_cmos",
> SYMLINK+="rtc"
>
Actually, it need not be that complex:

  SUBSYSTEM=="rtc", DRIVERS=="rtc_cmos", SYMLINK+="rtc"

This would preserve the "CMOS RTC is /dev/rtc" behaviour from previous
kernels, any additional RTCs wouldn't be linked there - but unless I'm
misunderstanding this, the kernel never had a /dev/rtc for those before
anyway.

> 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.
>
After talking to upstream, I'm convinced that anything fancier should
enumerate RTC devices the "modern" way.

Preserving the /dev/rtc symlink for the CMOS driver is correct though.

Scott
--
Scott James Remnant
<email address hidden>

This bug was fixed in the package udev - 124-8

---------------
udev (124-8) intrepid; urgency=low

  * debian/rules.d/60-symlinks.rules:
    - Add /dev/rtc symlink pointing to the CMOS RTC if it exists (almost
      always rtc0, but we match properly by driver). LP: #252924.

 -- Scott James Remnant <email address hidden> Fri, 24 Oct 2008 10:45:31 +0100