| |||||||||||||
Kernel configuration for distributionsKernel configuration for distributionsPosted Jul 22, 2012 9:33 UTC (Sun) by DavidS (subscriber, #84675)In reply to: Kernel configuration for distributions by dlang Parent article: Kernel configuration for distributions
> You will have a ~3-5 month lag between the time the distro defines
> a minimum and when a kernel release comes out that includes it.
Except when those updates qualify as stable updates. Which I believe they should.
Or when everyone get's their act together and when a new kernel releases it already has the "right" set of definitions.
(Log in to post comments)
Kernel configuration for distributions Posted Jul 22, 2012 9:53 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
> Except when those updates qualify as stable updates. Which I believe they should.
-stable could be redefined to allow this, but since this is adding functionality, not fixing a bug, it wouldn't fit the current definition.
> Or when everyone get's their act together and when a new kernel releases it already has the "right" set of definitions.
I don't see how that is possible.
month M kernel.org releases 3.4, starts development on 3.5
Month M+1 distro A decides their next release (version 10, to be released in 3 months) will be based on 3.4 starts defining minimum requirements for the next release
Month ~M+3 kernel.org releases 3.5 starts work on 3.6
Month M+4 distro A finalizes the version 10 release (based on 3.4) and now has the final definition for the minimum requirements. Distro A submits these upstream, Linus allows the patches past the merge window.
Month ~M+6 kernel.org releases 3.6 (with distro A version 10 minimum config embedded) and starts working on 3.7
multiply this out by hundreds of different distros.....
Remember that the kernel.org schedule is not fixed, it's working out to about 2.5-3 months (two week merge window plus 6-9 -rc releases before the final release) while the distros are on a fairly strict 6 month schedule. the distros aren't going to be trying to release the kernel that kernel.org is currently working on (if we are lucky, they are working on the release only one back, but it may very well be older than that)
Kernel configuration for distributions Posted Jul 22, 2012 9:56 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
If you are going to allow such patches in to -stable releases, and backport them to older kernels, how far back do you need to go? back to the kernel the distro uses for it's release? or back before that the the kernel the distro used for the prior release (so that you can try to find problems that were introduced by the new kernel in the release, think Intel video drivers a few years ago as an example)
If it's maintained outside of the kernel.org tree, then the distro can ship the appropriate config as it goes along, and it won't matter (much) which kernel you try to compile, the make oldconfig process will work with older and newer kernels (as long as they have the feature, and the feature has not grown a dependency one some other feature, it's not perfect, but it's pretty good)
Kernel configuration for distributions Posted Jul 23, 2012 19:21 UTC (Mon) by BenHutchings (subscriber, #37955) [Link]
Why would you downgrade the kernel on a new distribution?
Kernel configuration for distributions Posted Jul 23, 2012 19:50 UTC (Mon) by apoelstra (subscriber, #75205) [Link]
>Why would you downgrade the kernel on a new distribution?
I think the disconnect occurs when a distribution takes a (current) kernel, does several months on QA, then releases it -- and in the meantime, a new mainline kernel has come out.
Kernel configuration for distributions Posted Jul 23, 2012 20:39 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
if the kernel supplied by the new distro doesn't work on your hardware.
for example, there was a big problem a few years ago with Intel drivers in a Ubuntu release not working for many people. That is a perfect example of where you would want to move to an older kernel to keep working.
|
|||||||||||||