Re: [RFC][patch 00/12] clocksource / timekeeping rework V2
- From: Daniel Walker <dwalker@xxxxxxxxxx>
- Date: Fri, 31 Jul 2009 09:44:34 -0700
On Fri, 2009-07-31 at 01:34 -0700, john stultz wrote:
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.
It wouldn't need to be a module. The distro would update the kernel as
needed.. Just the act of loading an unauthorized kernel module would
potentially invalidate any distro support someone might get.. Distro's
typically provide backported fixes also.
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.
The IT guy more than likely would need to rebuild the kernel multiple
times to discover what the problem was .. In the end the distro would
push a fix for this to mainline, and provide a new kernel for the distro
users with a backported fix.
If there a potential for a clocksource to have some type of issue like
what you describe for the HPET, wouldn't it be easier to have all those
as tunable boot args or sysfs options ..
Daniel
--
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/
- References:
- Re: [RFC][patch 00/12] clocksource / timekeeping rework V2
- From: Martin Schwidefsky
- Re: [RFC][patch 00/12] clocksource / timekeeping rework V2
- From: Daniel Walker
- Re: [RFC][patch 00/12] clocksource / timekeeping rework V2
- From: Martin Schwidefsky
- Re: [RFC][patch 00/12] clocksource / timekeeping rework V2
- From: Daniel Walker
- Re: [RFC][patch 00/12] clocksource / timekeeping rework V2
- From: john stultz
- Re: [RFC][patch 00/12] clocksource / timekeeping rework V2
- From: Daniel Walker
- Re: [RFC][patch 00/12] clocksource / timekeeping rework V2
- From: john stultz
- Re: [RFC][patch 00/12] clocksource / timekeeping rework V2
- From: Daniel Walker
- Re: [RFC][patch 00/12] clocksource / timekeeping rework V2
- From: john stultz
- Re: [RFC][patch 00/12] clocksource / timekeeping rework V2
- Prev by Date: Re: [PATCH] Driver core: add new device to bus's list before probing
- Next by Date: Re: RomFS: enless loop during make oldconfig from 2.6.24 -> 2.6.31-rc4 (parisc)
- Previous by thread: Re: [RFC][patch 00/12] clocksource / timekeeping rework V2
- Next by thread: Re: [RFC][patch 00/12] clocksource / timekeeping rework V2
- Index(es):
Relevant Pages
|