On Fri, 20 Feb 2009, Alessandro Zummo wrote:
On Fri, 20 Feb 2009 16:46:44 +0100 Geert Uytterhoeven <Geert.Uytterhoeven@xxxxxxxxxxx> wrote:Fortunately there already exists a generic RTC class driver: "rtc-parisc". Despite it's name, it's platform-independent, as it's build on top of the RTC abstraction used by "genrtc". This patch series - adds a missing module alias to rtc-parisc, - renames rtc-parisc to rtc-generic, - converts the architectures that currently have CONFIG_GEN_RTC enabled in their defconfig (m68k, parisc, powerpc) to rtc-generic, - removes the obsolete rtc-ppc driver, - removes the old genrtc driver. Note that genrtc may be used on other archictectures as well: at least alpha has the required infrastructure ([gs]et_rtc_time()). The Kconfig rules allow genrtc to be enabled on several others (cris, h8300, mn10300, um, x86, xtensa). Furthermore genrtc and rtc-generic are not 100% userspace compatible: - /dev/rtc provided by genrtc uses a misc character device (10:135), - /dev/rtc provided by rtc-generic uses a dynamic character device.Hello, my opinion on this kind of stuff is that I want to avoid the layering of implementations under the rtc subsystem. I'd rather prefer that each rtc device had its own driver. I've made error in the past, by accepting such kind of drivers, and would like to avoid that it happens again.
So you want us to kill the ppc_md.[gs]et_rtc_time() [ppc], mach_hwclk() [m68k], mach_gettod() [m68knommu] (and probably a few other) abstractions, and move all RTC code out of arch/ into seperate drivers under drivers/rtc/ instead? What about ppc_md.get_boot_time() [ppc]? Please note that the functions above may also be used for very early clock setting (e.g. time_init()) and in read_persistent_clock(). How should we handle these? Even on x86 there seems to be way too much RTC logic in arch/x86/kernel/rtc.c (e.g. mach_get_cmos_time()), which is duplicated in drivers/rtc/rtc-cmos.c through the inline function __get_rtc_time() in include/asm-generic/rtc.h (clever, hardware-specific stuff in asm-generic ;-)
Regarding the user space, the assumption that a device has a fixed major:minor number should be dropped as well.
I know. But it's a userland-visible change, so I wanted to explicit point to it. With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone: +32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: Geert.Uytterhoeven@xxxxxxxxxxx Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010 -- To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
