Josh Triplett announced the release of Sparse v0.04. Originally written by Linux creator Linus Torvalds, Sparse has been maintained by Josh since 2006. Highlights of the new release include a new automated test suite invoked via 'make check', a new utility named 'c2xml' for generating an XML representation of C files, man pages for 'sparse' and 'cgcc', improved graphing, and numerous bug fixes. The project's web page explains:

"Sparse, the semantic parser, provides a compiler frontend capable of parsing most of ANSI C as well as many GCC extensions, and a collection of sample compiler backends, including a static analyzer also called 'sparse'. Sparse provides a set of annotations designed to convey semantic information about types, such as what address space pointers point to, or what locks a function acquires or releases."

Sam Ravnborg took a look at the x86 unification patches and commented, "from the mails and discussions I expected it be be obvious what was i386 only, what was shared and what was x86_64 only." He listed 16 files in x86/pci and noted, "in the filename there is NOTHING for most of the non-shared code that tell that this file is used by only i386 or x86_64." Andi Kleen concurred, "exactly my point from KS. The big mash-up will not really make much difference in terms of Makefile clarity or whatever Thomas' point was. Apparently he wanted to eliminate a few lines of code from the Makefile and merge the header files completely?"

Linus Torvalds disagreed saying, "the problem right now is the *reverse* - even though they are in different subdirectories (and thus *look* like they are all separate), they aren't. So the merged end result is much better: at a first approximation everything is shared (largely true), and the ones that aren't shared can be made more obvious." He added, "at least things like "grep" will work sanely, and people will be *aware* that 'Oh, this touches a file that may be used by the other word-size'." Linus continued:

"Right now, we have people changing 'i386-only' files that turn out to be used by x86-64 too - through very subtle Makefile things that the person who only looks into the i386 Makefile will never even *see*.

"THAT is the problem (well, at least part of it)."

"It turns out that USB devices suck when it comes to powermanagement issues :(" lamented Greg KH in posting some patches to handle USB autosuspend problems. He noted that the patches were intended for inclusion in the upcoming 2.6.23 kernel, "a number of patches have been submitted near the end of this kernel release cycle that add new device ids to the quirk table in the kernel to disable autosuspend for specific devices. However, a number of developers are very worried that even with the testing that has been done, once 2.6.23 is released, we are going to get a whole raft of angry users when their devices break in nasty ways." He proved an example, "it seems that almost 2/3 of all USB printers just can not handle autosuspend. And there's a _lot_ of USB printers out there..."

Later in the discussion, Linux creator Linus Torvalds commented, "in general, I think the USB blacklist/whitelists are generally a sign of some deeper bug." He continued on to point out a number of quirks in the USB layer that need to be addressed and added:

"We used to have a lot of those things due to simply incorrect SCSI probing, causing devices to lock up because Linux probed them with bad or unexpected modepages etc. I suspect we still have old blacklist entries from those days that just never got cleaned up, because nobody ever dared remove the blacklist entry.

"We should strive to make the default behaviour be so safe that we never need a black-list (or a whitelist), and basically consider blacklists to be not a way to 'fix up a device', but a way to avoid some really serious AND *RARE* error."

"This version has a lot of corrections, and is stable at least on my machine," noted Linus Torvalds in the 0.11 Linux kernel release announcment, "I /hope/ every known bug is fixed, but no promises (and all unknown bugs are still there, probably with reinforcements ;-)". The 0.11 kernel was released on December 8th, 1991, gaining demand loading, the mkfs, fsck and fdisk utilities, improved floppy drivers, a console that could generate beeps, support for US, German, French and Finnish keyboards, and settable line-speeds for the com ports (instead of having them hard-coded to 2400bps). Noticeably lacking was support for SCSI, an init/login system (Linux 0.11 booted into a root bash prompt), and paging to disk:

"Although I have a somewhat working VM (paging to disk), it's not ready yet. Thus linux needs at least 4M to be able to run the GNU binaries (especially gcc). It boots up in 2M, but you cannot compile."

Linus Torvalds announced the sixth release candidate of the upcoming 2.6.23 kernel, a final release expected within the next few weeks. He noted:

"So last week was a bust, with a lot of core people away for the kernel summit, and with -rc5 having two rather nasty (and silly) one-liner problems that bit a number of people - a missing NULL pointer check in TCP, and a missing list terminator in ata_piix.

"So the fixes for those things were both pretty trivial, and they've been in the -git trees for the last few days, but I just pushed out an -rc6 that also merges up some other updates that did come in during the week."

The -rc6 source level changes can be browsed via the gitweb interface.

Hua Zhong reported an NFS regression in 2.6.23-rc4 as compared to 2.6.22, "[upgrading] causes several autofs mounts to fail silently - they just [do] not appear when they should." Trond Myklebust explained that the change to default behavior was intentional to prevent an NFS mount from being mounted with the wrong options. The patch also introduced a new mount option, "the new option is there in order to make it damned clear to sysadmins that this is a dangerous thing to do: mounts which don't share the same superblock also don't share the same data and attribute caches. Any file or directory which appears in both mounts had better only be used by one application at a time or be using an appropriate locking scheme." Jakob Oestergaard defended the change asserting, "what he 'broke' is, for example, a ro mount being mounted as rw. That *could* be a very serious security (etc.etc.) problem which he just fixed. Anything depending on read-only not being enforced will cease to work, of course, and that is what a few people complain about(!)."

Linus Torvalds disagreed strongly with the change, "that commit gets reverted or fixed. It's a regression, and your theories that it's 'better' that way are obviously broken." He added:

"The point being that you just disallowed people from doing things that are sane but _potentially_ dangerous. That's not how we work. The UNIX way is to give people rope - if you cannot *prove* that what they are doing is wrong, then you damn well better not disallow it."

In response to the concern that the changes to NFS were necessary to fix a security hole, Linus retorted, "this is *not* a security hole. In order to make it a security hole, you need to be root in the first place. So what you call a security hole is really no different from root installing a bad SUID binary. It's simply not the kernels place to then say 'SUID binaries will not work, because it's a potential security hole'."

Linus Torvalds announced the fifth release candidate for the upcoming 2.6.23 Linux kernel noting that he was on his way to Cambridge, England, for the 2007 kernel summit. The invite-only kernel summit has been hosted in Ontario, Canada the past five years, this being the first year it has been hosted in Europe. It will happen over three days, from September 4'th through September 6'th.

Regarding 2.6.23-rc5, Linus noted, "hopefully we've addressed most regressions, so please do give it a good testing." He went on to summarize, "the shortlog and diffstat are appended: the diffstat is uglified by some powerpc defconfig updates, but otherwise it all looks pretty nice and small. The shortlog is fairly informative if you care about the details of what changed, but it does end up boiling down to 'fixing a number of generally pretty small issues'. Mostly in drivers and SCTP. So have fun, give it a go, and expect a quiet week next week."

"I've long hated the non-killability of tasks accessing a dead NFS server," Matthew Wilcox said along with a prototype patch to fix the issue based on a 2002 posting by Linus Torvalds. Matthew added, "I've only added one real user of the killable concept to this patch -- try_lock_page(). However, this is enough for 'cat */*/*' to be killable with a ^C when I unplug the ethernet cord between it and the nfs server."

Linus responded favorably to the patch, "hey, I obviously approve. And the patch looks simple." He went on to suggest that he was interested in merging the patch during the next merge window, "feel free to re-submit after 2.6.23 is out the door, I don't think anybody will really complain. Any NFS user will know why something like this can be really nice."

Linux creator Linus Torvalds announced the latest release candidate of the upcoming 2.6.23 kernel, "it can mostly be described with the one word, 'boring'", he said, noting there weren't any exciting changes. He added that there was two weeks between this and the last release candidate, summarizing:

"As a result, -rc4 is a bit bigger than it would/should have been, but hopefully it's all good, and we've fixed most regressions. There's some arch updates (MIPS, power, sparc64, s390) and an ACPI update, but the rest of it is mainly lots of small fixes (mostly to various random drivers). With some scheduler and networking noise."

Actual source-level changes can be viewed through the gitweb interface. Kernel Newbies maintains a list of all changes in the upcoming kernel.

"It's time to sanitize prototypes of bdev ->open(), ->release() and ->ioctl()," Al Viro began in an RFC posted to the Linux Kernel mailing list, "this stuff had sat in 'need to fix' for a long time and there is a bunch of bugs hard to fix without dealing with it." Following a detailed explanation of how he intends to meet this goal, he added, "[the] resulting APIs will be a lot saner and [the] entire thing is reasonably easy to split into bisect-friendly chunks. It is an API breaker, of course, but we don't have a lot of affected modules and anything not converted will be (a) immediately caught by gcc and (b) trivial to convert."

Linux creator Linus Torvalds responded favorably to the proposal, "from your description, I have no objections - everything sounds good. My only concern is how painful the patch ends up being (and a worry about whether this will affect a metric truck-load of external modules? That said, I can't really see us worrying about those)". Al noted that he would begin with a series of preparatory patches, "I have the beginning of that series done and the rest mapped out in enough detail to implement it over this week. If somebody has objections, questions or comments - yell."

In the continuining discussion about how GCC treats the volatile keyword, Linus Torvalds noted, "I just have a strong suspicion that 'volatile' performance is so low down the list of any C compiler persons interest, that it's never going to happen. And quite frankly, I cannot blame the gcc guys for it." He went on to explain, "that's especially as 'volatile' really isn't a very good feature of the C language, and is likely to get *less* interesting rather than more (as user space starts to be more and more threaded, 'volatile' gets less and less useful."

"So I wouldn't expect 'volatile' to ever really generate better code. It might happen as a side effect of other improvements (eg, I might hope that the SSA work would eventually lead to gcc having a much better defined model of valid optimizations, and maybe better code generation for volatile accesses fall out cleanly out of that), but in the end, it's such an ugly special case in C, and so seldom used, that I wouldn't depend on it.

"Quite frankly, I'd like there to be more competition in the open source compiler game, and that might cause some upheavals, but on the whole, gcc actually does a pretty damn good job."

A recent bug report led to a discussion about potentially dropping support for pre-4.0 versions of GCC. Adrian Bunk noted, "currently we support 6 different stable gcc release series, and it might be the right time to consider dropping support for the older ones. Are there any architectures still requiring a gcc < 4.0 ?" Russell King noted that on some architectures GCC 3.x is still preferable to the newer 4.x branch, "I want to keep support for gcc 3.4.3 for ARM for the foreseeable future. From my point of view, gcc 4 compilers have been something of a development thing as far as the ARM architecture goes. Also, gcc 3.4.3 is faster and significantly less noisy than gcc 4."

When it was asked how many kernel developers use older version of GCC, Linus Torvalds explained that it really doesn't matter, "it's NOT about 'kernel developers'. It's about random people testing kernels. If we make it harder for people to test kernels, we're going to lose. So no, I vote for *not* cutting off old gcc versions unless it's absolutely fatal."

"People who think 'volatile' really matters are just fooling themselves," Linus Torvalds quipped during a lengthy discussion on the Linux Kernel mailing list. The thread began with a series of patches to "make atomic_read() behave consistently across all architectures" which included "removing the volatile keyword from all atomic_t and atomic64_t definitions that currently have it, and instead explicitly [casting] the variable as volatile in atomic_read()."

Earlier in the discussion Linus had suggested that while it didn't actually fix any bugs it did help hide bugs and make them less likely to be triggered, "and hey, sometimes 'hiding bugs well enough' is ok. In this case, I'd argue that we've successfully *not* had the volatile there for eight months on x86-64, and that should tell people something. " But later in the discussion he related it to superstitions like the fear of a black cat crossing the road, which "has no bigger and longer-lasting direct affects":

"In other words, this whole discussion has just convinced me that we should *not* add back 'volatile' to 'atomic_read()' - I was willing to do it for practical and 'hide the bugs' reasons, but having seen people argue for it, thinking that it actually fixes something, I'm now convinced that the *last* thing we should do is to encourage that kind of superstitious thinking."

In a June of 1992 posting to the linux-activists mailing list, Linus Torvalds described the original Linux scheduler noting, "the scheduler in linux is pretty simple, but does a reasonably good job at giving good IO response while not being too unfair against cpu-bound processes." A year later, Linus posted a more detailed description of the scheduler noting, "the linux scheduling algorithm is one of the simplest ones possible". Comments in the original 254 line sched.c file read, "'schedule()' is the scheduler function. This is GOOD CODE! There probably won't be any reason to change this, as it should work well in all circumstances (ie gives IO-bound processes good response etc). The one thing you might take a look at is the signal-handler code here."

Comments in the current 6,709 line sched.c file show the first changes being made in 1996 by Dave Grothe, "to fix bugs in semaphores and make semaphores SMP safe". Two years later Andrea Arcangeli is credited with implementing "schedule_timeout() and related stuff". It was not until 2002, ten years after Linus' original code was written, that the scheduler received a complete rewrite, "new ultra-scalable O(1) scheduler by Ingo Molnar: hybrid priority-list and round-robin design with an array-switch method of distributing timeslices and per-CPU runqueues." Con Kolivas is credited with "interactivity tuning" in 2003, and Nick Piggin added "scheduler domains" in 2004. A more recent rewrite of the scheduler happened in April, again by Ingo Molnar, this time with his Completely Fair Scheduler.

"Either people really are calming down, and figuring out that we're in the stabilization phase," Linus Torvalds began in announcing 2.6.23-rc3, "or it's just that it's the middle of August, and most everybody at least in Europe are off on vacation." The actual source-level changes can be browsed via the kernel.org gitweb interface. Linus went on to summarize:

"Regardless of why, -rc3 is out, and doesn't have the tons of changes that -rc2 did. But there's some scheduler updates, sparc64 and powerpc changes, and random driver updates (the lpfc SCSI driver kind of stands out in the diffstat).

Shortlog appended, I don't know what I can add to it.. Please do give it a good testing, unless you're on a beach sunning yourself (and who are we kidding: you're pasty white, and sand is hard to get out of the keyboard - beaches are overrated)."