: 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
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
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.
to post comments)