[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <1261540762.3508.61.camel@localhost.localdomain>
Date: Tue, 22 Dec 2009 19:59:22 -0800
From: john stultz <johnstul@...ibm.com>
To: lkml <linux-kernel@...r.kernel.org>
Cc: Richard Henderson <rth@...ddle.net>, linux-alpha@...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>,
Paul Mundt <lethal@...ux-sh.org>,
"David S. Miller" <davem@...emloft.net>
Subject: [RFC][PATCH 0/14] Convert remaining arches to
read/update_persistent_clock
So as the timekeeping system has become more and more generic, folks
have been careful to allow a slow and steady evolution without breaking
all the arches at once, allowing each arch maintainer to convert over to
generic code when they're ready.
However, this slow conversion has forced us to keep multiple methods for
various functionality around, cluttering up the code and making
maintenance more difficult. Further, there's no central road-map or
notification to maintainers on when these new generic functions appear,
so its likely folks wouldn't notice until the old interfaces were
removed.
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.
I'm posting this tonight in somewhat rough form (none of the code has
been compiled or tested) so I can get feedback tomorrow before I'm off
on vacation until the new year. I'd like to get these changes into
2.6.34 so further generic cleanups can be made.
Let me know what you think.
thanks
-john
--
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/
Powered by blists - more mailing lists