Kernel configuration for distributions [LWN.net]

Kernel configuration for distributions

Posted Jul 20, 2012 5:09 UTC (Fri) by dlang (guest, #313)
Parent article: Kernel configuration for distributions

actually Alan Cox posted the code that would need to be included in the kernel tree (see http://lists.opensuse.org/opensuse-kernel/2012-07/msg0008... for Alan explaining what I was fumbling for in a very concise way)

> However providing you separate the initial profile from the later tools
> it simply becomes
>
> make distroconfig
> [cp /etc/system-kconfig(.$ARCH?) .config
> make oldconfig]
>
> make menuconfig (if you want to customise)

the effort will be around creating the distro specific options.

If the solution ends up being miniconfig like, then the distros produce snippets of .config that contain their requirements

If the solution is additional selection items in the kconfig system, then the distros will need to produce the appropriate kconfig code to select the right things.

In either case, the hardest work is going to be figuring out what the correct options should be.

the biggest reason I would prefer to see the miniconfig approach is that it allows each distro to provide the appropriate file as part of the distro update process.

This avoids the risk of a huge amount of distro specific code in the kernel.org tree. And the political questions like how big does a distro need to be to get it's config included in kernel.org, how long after release does it remain there. There are hundreds of distros out there and at the other extreme a single Debian release can produce 30-40 different kernel configs (although defining 'minimum' tightly enough can reduce this).

Linus complained a few years ago about the horrible defconfig churn, putting the per distro, per release info in the kernel config seems like it is begging for the same sorts of problem.

There will also be a gap between the time the distro releases a version and when the minimum config for that version can get into the kernel.org tree. 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. As a result, the first kernel.org kernel that will have the 'proper' minimum config for a distro will be at least two revisions newer than the version the distro ships.

However, I'm not a kernel developer, I'm 'just' a sysadmin who's been using linux since the 0.99 days My contribution consists of testing and feedback, so while I can warn of problems that I see with an approach, and try to convince others. Ultimately this is going to be up to the distro maintainers to decide which approach they are going to be willing to implement.

to post comments

Kernel configuration for distributions

Posted Jul 22, 2012 9:33 UTC (Sun) by DavidS (guest, #84675) [Link] (5 responses)

> 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.

Kernel configuration for distributions

Posted Jul 22, 2012 9:53 UTC (Sun) by dlang (guest, #313) [Link] (1 responses)

> 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 (guest, #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] (2 responses)

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 (guest, #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.