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 using the wrong device node on a system with
multiple hardware clocks?

Simply unknown.  I imagine such systems have things like GPS devices,
time signal devices, crypto devices, etc.

Having software suddenly read and write from one of those clocks instead
of the one on the motherboard could have quite serious consequences.
(Especially in the crypto device case).

The documentation for the rtc class even points out that some devices
don't implement the same commands as others - symlinking the device to
the wrong one could cause errors and buggy behaviour.

Scott
-- 
Scott James Remnant
<email address hidden>