linux-kernel - Re: [RFC][PATCH 0/14] Convert remaining arches to read/update_persistent

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:	Wed, 23 Dec 2009 14:08:10 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	john stultz <johnstul@...ibm.com>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	Richard Henderson <rth@...ddle.net>,
	linux-alpha@...r.kernel.org, linux-sh@...r.kernel.org,
	Russell King <linux@....linux.org.uk>,
	Haavard Skinnemoen <hskinnemoen@...el.com>,
	Mike Frysinger <vapier@...too.org>,
	Mikael Starvik <starvik@...s.com>,
	David Howells <dhowells@...hat.com>,
	Yoshinori Sato <ysato@...rs.sourceforge.jp>,
	Tony Luck <tony.luck@...el.com>,
	Hirokazu Takata <takata@...ux-m32r.org>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Koichi Yasutake <yasutake.koichi@...panasonic.com>,
	Kyle McMartin <kyle@...artin.ca>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [RFC][PATCH 0/14] Convert remaining arches to read/update_persistent_clock

On Tue, Dec 22, 2009 at 07:59:22PM -0800, john stultz wrote:
> In this case the generic read_persistent_clock() and
> update_persistent_clock() methods have been provided to allow the
> generic timekeeping code to initialize xtime and set the persistent
> clock when NTP is synced. However many arches haven't converted, so the
> generic code has to handle the case where the arch is doing this
> management itself.
> 
> This patch series tries to convert the following 14 architectures over
> to use read_persistent_clock() and update_persistent_clock() as
> applicable, killing off about 200 lines of arch specific code.
> 
While I think that this is a good goal, many of the underlying
architectures have veered pretty far away from having meaningful
persistent clock interfaces after having moved entirely to generic
timekeeping and the RTC subsystem.

In the case of SH at least that interface along with the generic CMOS
stuff is largely a stop-gap for antiquated platforms that don't have
proper RTC drivers and likely never will, while the default for all of
the rest of the platforms effectively returns a fixed dummy value. I
copied this approach from MIPS originally, so there are at least a few
architectures that this will apply to.

In any event, I wonder if it might make more sense to take something like
the SPARC implementation that is simply a wrapper around the RTC, move
that out in to a more generic place, and permit architectures to select
an RTC class backed persistent clock instead (it seems to be only
platforms that haven't caught up yet in terms of generic time and RTC
migration that would want to define this interface on their own at all at
this point)?
--
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/