[rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver

[Alessandro Zummo]

On Mon, 2 Mar 2009 11:28:01 +0100 (CET)
Geert Uytterhoeven <Geert.Uytterhoeven at sonycom.com> wrote:

> So I can solve my problem (autoloading the RTC driver on PS3 by udev) by
> converting the old genrtc driver into a platform device driver and creating
> platform devices where appropriate.

 yes. btw, if you are building a kernel specific for the PS3, I would
 compile the rtc driver statically, otherwise it won't be available
 early on boot.
 
> However, this doesn't solve the distro's problem: as the old RTC framework
> depends on RTC_LIB=n, you cannot have both old and new RTC drivers in your
> (single) distro kernel. That's why dmwm2 created drivers/rtc/rtc-ppc.c: Fedora
> had to support machines with both old and new RTC drivers. As all of the old
> drivers are actually behind the ppc_md.[sg]et_rtc_time() abstraction, this was
> very easy.

 ok, generic kernel. you will have to load the modules on initrd. no, sadly you
 can't have both of them. you might stick with the old interface or
 convert them all. 

> Hence it's all or nothing, and we have to convert all of them.
> 
> drivers/rtc/rtc-generic.c would allow to have a working system without old
> RTC drivers, until all low-level code has been converted to individual RTC
> drivers.

 I know but I have enough experience to foresee that once a generic over generic
 framework is in place it's very hard to get rid of it because people
 will have no incentives.

 If you really need rtc-generic you can keep using it even if it's 
 not in the kernel, distributions often have their specific
 set of kernel patches.

 But I'd strongly suggest to plan and execute a conversion process.


> >  Layering a generic framework over another generic framework
> >  is quite a nonsense . 
> 
> IMHO these two generic frameworks are quite different: [sg]et_rtc_time()
> abstracts the low-level RTC hardware interface, while RTC class handles the
> interaction with userspace.

 When I wrote it my intention was to make it as an abstraction _between_
 the userspace and the hardware according to the platform/device model.

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it