Re: [PATCH 0/4] PM: Do not destroy/create devices while suspended (rev. 2)

quoted

quoted

shouldnt we provide a Kconfig way of replacing dev 10:135 with the 
new driver's 254:0 device? (while keeping all the current modes of 
operation as well, of course.) It's all supposed to be 100% ioctl 
ABI compatible with the old driver, right?

It's not compatible enough to "fake" only the old major/minor. Userspace
must be fixed not to depend on stuff like:  /proc/sys/dev/rtc/max-user-freq:
  http://lkml.org/lkml/2007/8/4/183

i think that should be fixed by providing a compatible 
/proc/sys/dev/rtc/max-user-freq implementation in the new driver too.

I see /sys/class/rtc/rtc0/max_user_freq, fwiw ...

quoted

quoted

That way distros could start migrating to it
as well, without depending on any udev hackery.

It's in the default udev setup:
  KERNEL=="rtc|rtc0",             MODE="0644"
  KERNEL=="rtc0",                 SYMLINK+="rtc"

but if it breaks max-user-freq (which is needed by qemu for example) 
then distros would likely disable it, right?

or this rule might be broken in some way. For example my Fedora 8 box 
has this in /etc/udev/rules.d/50-udev-default.rules:

 # miscellaneous
 KERNEL=="fuse",                 MODE="0666"
 KERNEL=="rtc|rtc0",             MODE="0644"
 KERNEL=="rtc0",                 SYMLINK+="rtc"

still i've got:

 crw------- 1 root root  10, 135 Dec 28 08:13 /dev/rtc
 crw-r--r-- 1 root root 254,   0 Dec 28 08:13 /dev/rtc0

I suspect the /dev/rtc node was provided by the distro, so those
udev rules won't trigger.

_and_ my distro kernel doesnt even have CONFIG_RTC enabled - i run the 
Fedora 9 devel/rawhide kernel on this box:

 # CONFIG_RTC is not set
 # CONFIG_GEN_RTC is not set
 # CONFIG_HPET_RTC_IRQ is not set
 CONFIG_RTC_LIB=y
 CONFIG_RTC_CLASS=y
 # CONFIG_RTC_HCTOSYS is not set
 # CONFIG_RTC_DEBUG is not set
 # RTC interfaces
 CONFIG_RTC_INTF_SYSFS=y
 CONFIG_RTC_INTF_PROC=y
 CONFIG_RTC_INTF_DEV=y
 # CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
 # CONFIG_RTC_DRV_TEST is not set

udev-116-3.fc8.

I run my x86 systems like that (also with RTC_DRV_CMOS), but
the ARM systems usually have RTC_HCTOSYS set too (plus some
RTC driver other than rtc-cmos).  The x86 system init code
pokes directly at the legacy RTC hardware in several cases.

Maybe i just misunderstood what the grand plan was here 
- i assumed it was to smoothly convert from old driver to new driver, 
without forcing any changes on user-space.

If there was a Grand Plan, I never heard of it. :)

It'd need to have some NTP sync solution for RTC_LIB devices, but
ISTR the gentime stuff still assumes an update_persistent_clock()
that doesn't sleep ... and hence can't be used with I2C based RTCs.


I've been trying to make sure the x86 world could realistically
switch to the RTC framework used by other Linux platforms, hence
e.g. the util-unix-ng updates, but never assumed there would be
no userspace changes.  After all, userspace was using a mishmash
of tools that were far from platform-agnostic, and moving away
from x86-dependency implies such things will change.

However I *do* think that symlinking rtc to /dev/rtc0 should
make it practical to use most older binaries.

- Dave