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

[john stultz]

On Thu, 2009-07-30 at 22:33 -0700, Daniel Walker wrote: 
> On Thu, 2009-07-30 at 13:56 -0700, john stultz wrote:
> > 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. 
> 
> I'm not sure I understand your example.. Your saying a situation where
> the kernel can't modified and reloaded, and the hardware clocks aren't
> fully implemented in code yet?

Right. Distro kernels. 

> > 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.
> 
> You can just as easily back port the code as a built in, and reload the
> kernel right? Why would it need to be a module?

Again, distro kernels. Users can't rebuild them without possibly losing
the support they've paid for, and often recompiling them can cause 3rd
party drivers to fail to work (some distros preserve kernel ABI
stability between minor releases). Waiting 6 months or two years for the
next release where everything is fixed upstream isn't going to make
users happy.

Now, with most hardware vendors implementing decent HPET/ACPI PM
counters, maybe this case is more me reacting to a bad situation I had
to deal with in the past then what we can realistically expect in the
future. But given hardware designers like to break assumptions to
squeeze out performance or features, I'd suspect there will be future
situations where having some extra flexibility would be valuable.

Imaginary example: broken BIOS has incorrect HPET freq and the TSCs are
not in sync. Savvy IT dude finds the problem, copies the HPET driver,
names it hpet-fix and hard codes the proper HPET freq in. Sets the
rating higher then HPET, builds it as a module and loads it on the
affected hardware.

Suddenly there's a solution where otherwise none might be possible.

thanks
-john


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