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



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/



Relevant Pages

  • Re: Distributions
    ... | general there are a lot of packages for people to use. ... kernel, have to run on a multitude of different systems, they tend to be ... and slower than if you compile those packages, ... can have that stability with virtually any distro. ...
    (Debian-User)
  • Re: wpa supplicant/ipw3945, ESSID last char missing
    ... but who want to upgrade to a newer 2.6 kernel? ... I'd point out here that one is not breaking the _distro_, ... We've _got_ to accept that somebody installing their own stuff has ... and no new interface is introduced without thinking very ...
    (Linux-Kernel)
  • Re: Where are all the updates gone?
    ... base distro they were building it on, so when they went looking, the 18 ... kernel modules needed to run the realtime portions of emc's control ... you watch this little machine carve out whatever I can write the code to ... Copyright 2007 by Maurice Eugene Heskett, ...
    (Fedora)
  • Re: [RFC] Unify KVM kernel-space and user-space code into a single project
    ... distros update the kernel first. ... this is what i said is the distro practice these days. ... I'm sure if we ask the Fedora qemu maintainer to package qemu-kvm.git ... hosting KVM user-space bits in the kernel together with the rest of KVM you ...
    (Linux-Kernel)
  • Re: RFC: Starting a stable kernel series off the 2.6 kernel
    ... >> small projects writing for example a wifi driver or a security patch ... >> or whatever without full time commitment to tracking kernel changes. ... >> for custom distro kernels). ...
    (Linux-Kernel)