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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090302120950.0d35e06c@i1501.lan.towertech.it>
Date:	Mon, 2 Mar 2009 12:09:50 +0100
From:	Alessandro Zummo <alessandro.zummo@...ertech.it>
To:	Geert Uytterhoeven <Geert.Uytterhoeven@...ycom.com>
Cc:	Richard Zidlicky <rz@...ux-m68k.org>, rtc-linux@...glegroups.com,
	David Woodhouse <dwmw2@...radead.org>,
	linux-parisc@...r.kernel.org,
	Linux Kernel Development <linux-kernel@...r.kernel.org>,
	Kyle McMartin <kyle@...artin.ca>,
	Linux/PPC Development <linuxppc-dev@...abs.org>,
	Linux/m68k <linux-m68k@...r.kernel.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Subject: Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver

On Mon, 2 Mar 2009 11:28:01 +0100 (CET)
Geert Uytterhoeven <Geert.Uytterhoeven@...ycom.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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/