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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 27 Feb 2009 19:55:14 +0100
From:	Richard Zidlicky <rz@...ux-m68k.org>
To:	Alessandro Zummo <alessandro.zummo@...ertech.it>
Cc:	rtc-linux@...glegroups.com, Geert.Uytterhoeven@...ycom.com,
	David Woodhouse <dwmw2@...radead.org>,
	linux-parisc@...r.kernel.org,
	Linux Kernel Development <linux-kernel@...r.kernel.org>,
	David@...abs.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 Wed, Feb 25, 2009 at 11:18:36AM +0100, Alessandro Zummo wrote:
> On Wed, 25 Feb 2009 11:00:13 +0100 (CET)
> Geert Uytterhoeven <Geert.Uytterhoeven@...ycom.com> wrote:
> 
> > I didn't know NTP was broken with RTC class drivers?
> > 
> > So we should actually keep on using genrtc instead of rtc-ppc/rtc-generic for
> > now? ;-)
> 
>  broken here means that the kernel won't save the time to the hardware
>  rtc every 11 minutes as it used to do. normal NTP operations are unaffected.

seems like so far ppc is the only architecture attempting to implement it
correctly, all others either have it unimplemented or use the broken
by design set_rtc_mmss method. 
Also note that in most cases hwclock has much better possibilities
to do a good job.

Regarding genrtc vs rtc-ppc/rtc-generic it is worth noting that genrtc
provides RTC_UIE emulation which is of some use for exotic programs like 
"chrony".
Afaics this is also the only situation without a good userspace workaround 
and chrony never worked well for me so I have nothing against junking the 
code.

Regarding a possible reorganisation from the generic to all separate drivers
I agree that the habit of putting rtc-chip specific code in asm-generic is 
confusing at best. 
In many cases such code might be better placed in drivers/rtc or 
include/linux/rtc/chipname.

Imho this does not preclude the possibility to use a generic framework. While
there certainly are valid reasons to have separate drivers in some cases 
I do not see much value in rewriting everything as separate drivers where 
the generic framework works well.

Richard
--
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/