"Ok, the last -rc obviously wasn't the last one after all, since here's a new one," noted Linus Torvalds, announcing the 2.6.26-rc9 kernel. He continued, "enough changes that we needed another -rc, and the regression list isn't emptying fast enough either (probably because a number of people, including reporters, are vacationing)." He went on to summarize:

"The actual bulk of this all is a new UVC video driver for the standard USB Video Class specification. It's a new driver, so shouldn't cause any regressions, but it's fairly sizable [...] ie 78% is just that one new driver, and almost 92% is driver updates in general (although some of them are reverts, so they show up as diffs against -rc8, but they actually cause the _total_ diff against 2.6.25 to shrink a bit). The fs updates are partly some minor updates to 9p, ecryptfs, proc and udf, but partly some delayed cleanup patches that went through Al. Bad Al. But when Al sends me patches, I apply them. I worry what would happen if I didn't. The rest is mainly small fixes (one-liners and 'few-liners') all over the place, many of them merged from Andrew's -mm queue."

A thread on the Linux Kernel mailing list discussed the process in place for reporting, bisecting and fixing bugs. In response to a suggestion that some of the issues could be solved by introducing new procedures, Al Viro retorted, "we've got ourselves a developing beaurocracy. As in 'more and more ways of generating activity without doing anything even remotely useful'. Complete with tendency to operate in the ways that make sense only to bureaucracy in question and an ever-growing set of bylaws..." Later in the thread, David Miller agreed and noted that ,"the resulting 'bureaucracy' or whatever you want to call it is perceived to undercut the very thing that makes the Linux kernel fun to work on. It's still largely free form, loose, and flexible. And that's a notable accomplishment considering how much things have changed. That feeling is why I got involved in the first place, and I know it's what gets other new people in and addicted too."

Andrew Morton tried to return the discussion to its original topic, "the problem we're discussing here is the apparently-large number of bugs which are in the kernel, the apparently-large number of new bugs which we're adding to the kernel, and our apparent tardiness in addressing them." Al noted that some of the problem is that git is so efficient at merging code, "the patches going in during a merge (especially for a tree that collects from secondaries) are not visible enough. And it's too late at that point, since one has to do something monumentally ugly to get Linus revert a large merge. On the scale of Great IDE Mess in 2.5..." Another suggestion was made to replace bugzilla with something better, to which Andrew replied, "swapping out bugzilla for something else wouldn't help. We'd end up with lots of people ignoring a good bug tracking system just like they were ignoring a bad one."

"[The] text below is mostly for the benefit of newbies - it's more along the lines of 'how to get from [a] bug report to the source of [the] bug', with more details than normal," began Al Viro, offering a full review of another Linux kernel oops in an effort to educate more people on how this is done. Al's walk through included a patch to fix the bug that caused the oops. He noted:

"This might be worth doing on [a] more or less regular basis, especially if more people join the fun; everyone [has] their own set of tricks in [this] area and making it easier to gather might help a lot of people. It's not just about oops-tracing per se, of course - Arjan's site gives a nice collection of those, so that makes an obvious starting point."

"This week, a total of 49 oopses and warnings have been reported, compared to 53 reports in the previous week," Arjan van de Ven noted, sending out a list of the week's top 10 kernel oopses. Al Viro suggested, "FWIW, people moaning about the lack of entry-level kernel work would do well by decoding those to the level of 'this place in this function, called from <here>, with so-and-so variable being <this>' and posting the results." This was met by multiple requests for documentation on how to actually decode an oops. Linus Torvalds explained:

"It's actually not necessarily at all that trivial, unless you have a deep understanding of the code generated for the architecture in question (and even then, some oopses take more time to figure out than others, thanks to inlining and tailcalls etc). If the oops happened with a kernel you generated yourself, it's usually rather easy. Especially if you said 'y' to the 'generate debugging info' question at configuration time."

Linus went on to detail how to debug a random oops reported on the lkml, "you will generally have to disassemble the hex sequence given in the oops (the 'Code:' line), and try to match it up against the source code to try to figure out what is going on." He then offered a number of tips on how this is best accomplished, continuing with an example walking through one of the reports oops. Al Viro replied describing his own methods of accomplishing the same thing, walking through of another oops and isolating a bug.

Jaroslav Sykora posted a series of five patches to handle the kernel portion of what he described as "shadow directories", providing an example which utilized FUSE to access the contents of a compressed file from the command line. His first example was cat hello.zip^/hello.c about which he explained, "the '^' is an escape character and it tells the computer to treat the file as a directory. The kernel patch implements only a redirection of the request to another directory('shadow directory') where a FUSE server must be mounted. The decompression of archives is entirely handled in the user space. More info can be found in the documentation patch in the series."

There were numerous problems suggested. Jan Engelhardt noted, "too bad, since ^ is a valid character in a *file*name. Everything is, with the exception of '\0' and '/'. At the end of the day, there are no control characters you could use." Later in the thread an lwn.net article from a couple years ago was quoted, "another branch, led by Al Viro, worries about the locking considerations of this whole scheme. Linux, like most Unix systems, has never allowed hard links to directories for a number of reasons;" The article had been discussing Reiser4, which treats files as directories. In the current discussion, Al Viro added, "as for the posted patch, AFAICS it's FUBAR in handling of .. in such directories. Moreover, how are you going to keep that shadow tree in sync with the main one if somebody starts doing renames in the latter? Or mount --move, or..."

"15 partitions (at least for sd_mod devices) are too few," Jan Engelhardt suggested along with a patch to try and make the mounting of an unlimited number of partitions possible. H. Peter Anvin proposed as an alternative, "now when we have 20-bit minors, can't we simply recycle some of the higher bits for additional partitions, across the board? 63 partitions seem to have been sufficient; at least I haven't heard anyone complain about that for 15 years."

Alan Cox explained, "this was proposed ages ago. Al Viro vetoed sparse minors and it has been stuck this way ever since. If you have > 15 partitions use device mapper for it. I'd prefer it fixed but it's arguable that device mapper is the right way to punt all our partitioning to userspace".

"If you have the ability to use chroot() you are root. If you are root you can walk happily out of any chroot by a thousand other means," Alan Cox explained during a thread that suggested chroot was broken in Linux. It was further pointed out that this was true per the POSIX specification, and per other OS's implementations. Al Viro suggested this should be added to the lkml FAQ, explaining:

"If you are within chroot jail and capable of chroot(), you can chdir to its root, then chroot() to subdirectory and you've got cwd outside of your new root. After that you can chdir all way out to original root. Again, this is standard behaviour. Changing it will not yield any security improvements, so kindly give that a rest."

When it was suggested that chroot is frequently used as a security tool, Adrian Bunk retorted, "incompetent people implementing security solutions are a real problem." Alan added, "chroot is not and never has been a security tool. People have built things based upon the properties of chroot but extended (BSD jails, Linux vserver) but they are quite different."

Discussion continues on the Linux Kernel mailing list about the legality and morality of re-licensing BSD/GPL dual-licensed code under only the GPL. Alan Cox replied to Theo de Raadt's comments suggesting he was encouraging people to break the law, "re-read my email and then apologize. I do question the .h files where they are BSD licence and no changes were made to the work. I also point out that the dual licence on that code appears to give permission to distribute under one of those licences by choice." In response to Theo's request that code be shared both ways rather than converted to a sole GPL, "that's about the first thing I would agree on - its somewhat rude and not something I personally would usually choose todo." He then cautioned that this was a limitation of the BSD license:

"If OpenBSD wants a world where code must be returned, but you can mix it with free code in a product in some fashion and do binary only releases then OpenBSD needs to fix its licencing. Not to GPL which is clearly not the BSD intention but to something which does what BSD wants rather than an academic research licence developed thirty odd years ago for the purpose of showing that US research funds were properly spent. Perhaps its time for BSD2 licencing?"