Thoughts about the Debian kernel
I am one of the guys who builds Linux kernels locally, from vanilla sources. What I don't like in this approach is that I do not get the distribution patches and might miss one of the kernel security patches, since I am way too busy to keep track of LKML any more. otoh, I am kind of a version number junkie when it comes to the kernel, so the Debian kernel sources even in sid frequently are not current enough. So, what I want to have is a compromise between a vanilla kernel and the Debian distribution kernels, built in a way that the images integrate well with Debian.
This article contains a few questions and wishes directed towards the Debian kernel team.
I have tried to get some of them answered on #debian-kernel, but the people there were quite busy with other things and didn't answer. And while I was thinking and thinking more, and playing with the code, there were more and more questions until they became inappropriate for IRC. This is also my first try to get some discussion about technical Debian matters in the blogosphere, and I might use the insight gained here for a posting on the debian-kernel mailing list by the end of next week.
- The build process is not very transparent
- Documentation in the README files seems quite incomplete
- In my opinion, answers to these questions are missing:
- Which steps happen in which order (prose)?
- Are there any hooks to interfere with the build process?
- How to keep patches from being applied?
- How to add local patches?
- Is there anything like dpatch-edit-patch for the (home-grown?) patch system in the Debian kernel source package?
- How do I control generation of the kernel-image-2.x-<flavour><u>2.x.y-z</u><arch>.deb helper packages? They do not seem to be controlled by debian/arch/<arch>/defines as the real kernel debs do.
- Can I have patches from a kernel-patch-foo Package automatically applied for certain flavours?
- Are there hooks for building external modules?
- Are there debian/rules parameters or environment variables to select only a certain kernel to be built (like for debugging problems)?
- Can build of helper packages (-headers, -doc, -patch, -source, -tree) be disabled?
- For local kernel builds, should one use the Debian kernel build system, or continue to use make-kpkg as it was usual previously?
- there is nothing like a kernel HOWTO
- The Kernel Handbook needs to be fleshed out in these regards. I might want to contribute once I have accumulated the knowledge needed to write the passages.
- Patches like amd64-int3-fix need to be better commented
- I think it is necessary that a patch file contains information
- What does the patch do?
- why is it applied?
- is it necessary only on certain archs?
- is it necessary only if certain drivers are in use?
- what does happen when it is omitted?
- is it security relevant?
- CAN number, if applicable.
- Which role does module-assistant play here?
- If one builds kernels with make-kpkg, should make-kpkg also build the modules, or should one use module-assistant instead?
Trackbacks
No Trackbacks
Comments
Display comments as Linear | Threaded
Uwe Hermann on :
I'm tracking new kernel releases in my RSS reader (akregator), that actually works quite fine: http://kernel.org/kdist/rss.xml
No need to visit kernel.org daily or read LKML...
HTH, Uwe.
Marc 'Zugschlus' Haber on :
Tracking new kernel releases is not a problem, they don't release that often.
One of the biggest challenges, though, is spotting new vulnerabilities before the fix gets visible in a new release.
Mind Booster Noori on :
That's what the -stable branch is meant for...
Marc 'Zugschlus' Haber on :
Can you please elaborate? Which stable branch are you refering to?
Mind Booster Noori on :
The latest stable version of the Linux kernel is: 2.6.13.4
http://lkml.org/lkml/2005/10/10/172
http://www.kroah.com/log/2005/03/09/#stable_rules
Marc 'Zugschlus' Haber on :
So you still trust the kernel upstream people to timely issue updates for security problems? Sorry, I have lost that trust some three years ago.
Mind Booster Noori on :
Taking as an example the latest -stable kernel, it took 3 days to launch a version since the patches were written. Since there is no branch that do that quickier than that, you can only have the issues fixed quickier than 3 days (which I think it is an affordable time) if you're not too busy to keep track of LKML, which you stated as being.