linux-kernel - Re: [RFC][patch 00/12] clocksource / timekeeping rework V2

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: <1248987409.3374.5.camel@localhost>
Date:	Thu, 30 Jul 2009 13:56:49 -0700
From:	john stultz <johnstul@...ibm.com>
To:	Daniel Walker <dwalker@...o99.com>
Cc:	Martin Schwidefsky <schwidefsky@...ibm.com>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC][patch 00/12] clocksource / timekeeping rework V2

On Thu, 2009-07-30 at 11:08 -0700, Daniel Walker wrote:
> On Thu, 2009-07-30 at 10:16 -0700, john stultz wrote:
> > Clocksources as modules was one of the initial design goals I had way
> > back. The benefit being that an older distro kernel could be made to
> > support newer stranger hardware via a clocksource driver. While the
> > hardware vendors have for the most part consolidated on HPET/ACPI PM
> > which has mostly avoided the need, I still think its worth preserving.
> 
> If the PIT case is a real use case for unregister than we can keep it
> around. If not, then that path just becomes unused and all unused code
> is open for removal from my perspective.
> 
> If the case you describe above is a good one, then someone eventually
> will add back the unregister path. Which should come with a good reason
> and with an actual user of the code..

The case I describe above is one where the user of the code doesn't
necessarily have the ability to add back the unregister path. 

Old distro kernels can be difficult to make changes to when new hardware
is later released, so being able to just backport a module, compile and
load it to get a unexpectedly strange new bit of hardware to work with
an older distro kernel seems valuable enough to keep the code around to
me.

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/