Helping Automate Kernel Builds

Clifford Wolf has written a new makefile target, no2modconfig. Ordinarily, when you configure your kernel for compilation, any option in which you type N will not be compiled. With no2modconfig, those items are compiled into modules. Apparently, this is useful for auto-generating kernels.

Sam Ravnborg, it turns out, has some patches that do what Clifford wants in a way that uses the existing allmodconfig build target with a predetermined base config file. In response to Clifford's posting, Sam said he'd try to get his own solution ready to be reviewed in the near future.

Writing Under CramFS, SquashFS, and Others

Arnd Bergmann added write support to CramFS … sort of. Now the user is able to modify files on a running system, but the files themselves are never written to disk – the changes just hover in memory, and a reboot returns the system to its original state. Phillip Lougher says he's also planning to implement this sort of thing for SquashFS. Typically, past attempts involved the use of UnionFS to overlay a TmpFS instance on the filesystem in question. Arnd pointed out that UnionFS isn't actually the best solution and that coding the feature directly into CramFS is preferable to the hackiness of UnionFS. Phillip added that stackable filesystem support really belongs in VFS, which doesn't currently support it.

Enough people advocated using – or at least fixing – UnionFS to create a technical discussion about how that might be accomplished. Arnd and Phillip both said they'd be happy to compromise if UnionFS (or AUFS) could be made to do what they needed without too massive an effort, but the discussion ended inconclusively. To the kernel folks, it seems clear that pseudo-write support on CramFS and SquashFS (and possibly ISO 9660 as well) would help users, and the features should be supported one way or another.

Direction for 2.4

After what appeared to be a long hiatus, Willy Tarreau has been releasing more versions of the 2.4 kernel lately. Also, he's made some effort to compile some statistics about who uses that kernel and why they don't upgrade to the 2.6 kernel. With only 22 respondents, Willy's numbers have a pretty big margin of error, but they're still interesting. About half of the folks said they relied on 2.4 for general-purpose servers on which outages and upgrade regression problems would inconvenience a number of people, so they don't bother to upgrade to 2.6 and tend to keep the latest 2.4. About 20 percent of the respondents use 2.4 for application-specific servers, which tend to be "mission critical" servers on which any outage – even upgrading to the most recent 2.4 kernel – would be a big problem.

Approximately 10 percent of respondents use 2.4 for routers, firewalls, and other network deployment applications. In those cases, upgrading to 2.6 could be relatively easy because of the few system requirements, but folks aren't sure how to upgrade successfully, so they just stick with what they know.

Another 10 percent of respondents use 2.4 in their embedded systems products. In this case, taking the systems down for an upgrade would be visible to the customer and require substantial changes to the company's whole build process.

The rest of the respondents, approximately another 10 percent, run 2.4 on their personal systems, either because they didn't want to try to configure a new kernel for that hardware or because they were used to working on the system as-is and don't want any change at all.

Willy conducted the survey in part to figure out how to encourage more people to upgrade away from 2.4 so that tree could fade away peacefully. Willy's main recommendation for this was that the 2.6 folks produce a clear description of the functional differences between 2.4 and 2.6, so users are not left trying to figure out what is going to break on their own, and also that it is easily possible to go back to 2.4 if the upgrade doesn't go well.

Another reason for the survey was to make adjustments to Willy's 2.4 release schedule. He said, "I will issue stable releases a bit more often for users to quickly get their fixes, but progressively increase the delay between major releases." He continued by saying that major releases would only be issued with new PCI IDs, major driver updates, and compiler support, for example.