Linux Kernel Summit: Andrew Morton on Kernel Development

Andrew used a session at the kernel summit to provide general advice to linux kernel developers. Most of the device was targetted at the current process and focused on the representative leadership at the summit, although this advice should be heeded by anyone submitting code to the Linux kernel. Linus frequently jumped in with his own advice and support for Andrew. Here are a few of the excerpts that I captured.

Quilt/Git tree maintainers - please re-sync your tree as soon as you merge with Linus' tree.

At last year's kernel summit, maintainers agreed to send out a one-page summary of what they expected to submit in the next release. Kudos for Roland for actually doing this. The rest of you, please step up to the challenge.

Large patches like code cleanups, white space, lindent, code motion, etc. are proposed to go in right after -rc1. When those are applied and cleaned up - that will probably lead to -rc2. The x86 transmorgification would not be a good example for this, though.

Akpm sends out patches to subsystems maintainers which are only 30% or so applied or rejected by maintainers. Roland requested more clarity in the directions with those emails. Andrew clarified that cc: means review, To: line to the maintainer means to merge it or approve/reject it.

Andrew prefers to merge his 1000 patches *after* submitting the subsystem maintainer trees. Everyone thus usually gets two weeks, and Andrew gets 24 hours to merge 1000 patches. Linus is tired of subsystem mainatiners asking for merges in the last week (last day?) of the merge window. Subsystem maintainers who claim that there are conflicts in the merges are usually wrong and the merge should not take them so long. Linus wants subsystem trees (especially git trees) in the first DAY of the merge window.

Linus also really hates having people say "please pull my git tree" during -rc2 or -rc3. He tends to flame extensively for such travesties, primarily because otherwise he might just pull the tree is silent frustration. In other cases, Linus will silently no longer pull trees if they are outside the merge window. Subsystem maintainers should be enforcing this just like Linus does. Linus was *quite* blunt in his assertion of this policy and gently encouraged (with a large hammer and four letter words) that people help enforce this policy.

ACPI maintainers received kudos for hitting the merge window perfectly in terms of the previously described policy. The networking maintainer (Dave Miller) has been, um, a little more iffy lately, Linus said, somewhat tongue in cheek. All rules, of course, should be interpreted within the guidelines of common sense. Linus suggested that white space cleanups and such should then go into the end of the merge window.

Andrew pointed out that the -mm trees are now once every two weeks or so, as opposed to two a week. He plans to step that rate up again. Mel finds that the -mm tree is usually stable within 2-3 days and can be run on his machines by then. Andrew had promised to try to get daily snapshots out originally and gave up on it because the patchsets were actually seldom stable until he was ready to publish. Ben H. was asking for access to the patches that were going into -mm more frequently, even if the full tree was not functional. The -mm-commits list contains all of these patches as they are applied to the -mm tree.

Andrew believes that there should be some way for the kernel community to deliver user level applications to kernel users. There are about 15 .c files in the Documentation directory. It is not clear yet what the boundaries for inclusion in such a code directory. util-linux package used to be the place for all this per Christoph Helwig. Christoph will help move all the .c files from Documentation into util-linux. Balbir pointed out that there were some example code in Documentation; Christoph pointed out that that was the wrong place for it to be. He felt that util-linux would be the right place even to store basic examples. Maintainers is now Karel Zak (from RedHat) who forked util-linux which was previously unmaintained. The fork is called util-linux-ng.

Andrew was wondering if we were doing a good job of getting things back into the stable tree. He thinks that he is sending about 90% of the right stuff to the stable tree. Greg KH recommends adding stable@kernel.org to the cc: list of any bug fixes that are sent to Linux/Andrew so that they will see when these bugs are committed. There are 80-90 subsystem maintainers - Andrew encourages all of them to be considering which patches should be going to the stable tree.

Semantic checkers such as Sparse and Coverity are good and finding problems; however, some people are doing code motion rather than intelligent evaluation of the code. His example was tests for NULL at the end of a function are often getting moved up in the function, which may be correct, which shuts off the sparse/coverity warning, but in reality, the ideal patch may be to remove that test if that case really can not happen. In other words, use intelligence when fixing problems found by automated tools!