In brief

By Jonathan Corbet
August 5, 2009

TTY maintenance: Greg Kroah-Hartman, admitting that he is a glutton for punishment, has agreed to take on maintenance of the TTY layer - a job recently abandoned by Alan Cox. Patches have begun to flow toward the mainline, with Linus taking a larger-than-usual interest in getting them into shape. The fate of Alan's longer-term cleanup plans remains uncertain, but basic maintenance and bug fixing, at least, seems to be in place.

Regressions. Rafael Wysocki has posted the 2.6.31-rc5 known regressions list. A total of 76 regressions have been reported in this development cycle; 28 of those remain unresolved. For this stage in the process, that is about normal, or, perhaps, just a bit better than average. Less encouraging, perhaps, is the fact that the 2.6.30 regression list still shows 39 unresolved problems.

make V=1. Once upon a time, building a kernel filled the screen with vast amounts of output, including the full command line for each compilation command. Needless to say, it was hard to get much information out of that much noise; in more recent times, the kernel build system emits much more concise information about what it's doing. Sometimes, though, one needs to see what's really going on; in such cases, running "make V=1" will cause the build system to output everything it's doing.

Except that, as Dave Airlie discovered, it doesn't; some commands are still hidden from view even when V=1 is specified. Build system maintainer Sam Ravnborg explained: "The problem is that V=1 is already too chatty, so people sometimes hide their stuff - as in this case." His suggestion is to implement multiple levels of verbosity, so that "V=2" could be used to view the truly full stream of commands. There's a minor problem in that "V=2" is already used to get make to print out which file caused a particular rebuild to happen. But, as Sam puts it, few people ever use that option, so maybe it could be replaced with a "be more verbose" mode. Unless somebody objects soon, that's likely to be how it goes.

devtmpfs. Greg Kroah-Hartman, evidently not feeling sufficiently challenged by the TTY layer, has reposted the devtmpfs patch, suggesting that it's ready for merging into the mainline. Greg says:

For .32 it's a simple and clean patch. It's been tested and agreed by three major distros that this is a good idea. SuSE has been shipping this in their kernels for a while now with no problems, and actual speedups measured on their boot times.

It would be fair to say, though, that the development community is not yet sold on the desirability of merging this patch; expect some interesting discussion in the near future.

Xtables2. The future of Linux packet filtering might be nftables, but Jan Engelhardt isn't holding his breath. He has, instead, put together an immense patch set massively reworking the existing iptables mechanism. The internal data structures have been torn out and reimplemented as a more flexible linked list, setting the stage for easier single-rule changes in the future. Perhaps the biggest payoff, though, is in the unification of the IPv4, IPv6, and ARP versions of the packet-filtering engine; that, he says, enables the removal of about 50% of the code.

The initial responses suggested that potential reviewers were overwhelmed by the magnitude of the change. Jan has posted a more detailed explanation of what various groups of patches do, which has helped. Eventual merging of this code will probably require breaking the sequence up into multiple steps, though.

Montreal Linux power management mini-summit notes have been posted by Len Brown; they give a good (if terse) summary of recent developments in the area and what is being worked on now.