(Alessandro Zummo Cc:-ed too -- RTC subsystem maintainer)
Eventually, swapping driver modules ought to work too. The
legacy /proc/acpi/wakeup files would ISTR cause problems in
Of course, one reason to want to use the RTC framework code
is to stop depending on x86-isms like ACPI or "s2ram", and
thus to work on more Linux platforms. ;)
Current util-linux-ng code uses either RTC device file; and udev
sets up /dev/rtc0 as needed. (But not /dev/rtc, as I recall...)
Have distros switched away from the old unmaintained util-linux?
That might be so. There are some HPET issues, but those show up with
The main other issue I know about which would seem to argue for using
the legacy driver, instead of the RTC framework, is that some BIOSes
don't seem to provide PNPACPI entries for their RTCs. I got one report
of a newish HP Opteron system that doesn't. I have no idea how common
that is. The drivers/acpi/glue.c code could detect that, but maybe a
better place to address that would be in PNP code; in that case, ISTR
that PNP0c01 claimed the RTC ioports, and so would be the natural place
to make provide a real driver model node for that hardware.
The major number 254 is not statically allocated, ISTR; that should
be managed only by udev.
I don't know of any ioctl differences userspace would care about.