> > > 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 ... > > > 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 - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
