* Kay Sievers <kay.sievers@xxxxxxxx> wrote: > > 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. > > 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 _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. 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. Ingo - 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
