In a recent series of patches posted to the Linux Kernel mailing list, it was proposed that some imported Atheros wireless device drivers be re-licensed, some from a dual-BSD/GPL license, others from a modified BSD license, all to a pure GPLv2 license. Christoph Hellwig asked, "is this really a good idea? Most of the reverse-engineering was done by the OpenBSD folks, and it would certainly be helpful to work together with them on new hardware revisions, etc.." Luis Rodriguez suggested that there was no choice, "technically the best we can do is to leave the license as dual licensed, but keep in that technically that means nothing and is just for show, the GPL is what would apply as its derivative work and is the most restrictive license."

The patch series was also discussed on OpenBSD's -misc mailing list where it was asked, "is Reyk [Floeter] and others working on this drivers code dual licensed (from the diff it doesn't seem like it is, since I see a BSD 3 Clause)? Also say I submit a patch for this driver, does that mean this will have to be dual licensed also or can I choose if it is BSD 3 Clause or GPLv2?" Theo de Raadt replied pointing out that there are two parts to the driver, one part written by Reyk Floeter, and another part written by Sam Leffler, "Reyk's code is *NOT* dual-licensed under the GPL. He has explicitly stated that his code is not dual-licenced. The file have no GPL on them. He's the author, he said so. None else can add a GPL to it." He went on to note that the files written by Sam Leffler are dual licensed with the clause, "alternatively, this software may be distributed under the terms of the GNU General Public License ("GPL") version 2 as published by the Free Software Foundation," stressing that 'alternatively' means 'or', "that means that if anyone makes changes to that file and distributes it, after their changes are in the file then EITHER license will apply."

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."

"The elections for five of the ten members of the Linux Foundation Technical Advisory Board[TAB] are held every year, currently the election will be at the 2007 Kernel Summit in a BOF session," James Bottomley, the TAB chair, announced on the Linux Kernel mailing list. He noted that this voting session would be held on the evening of September 5'th or 6'th, providing an email address for sending nominations and adding that anyone is eligible, "only people invited to the kernel summit will be there in person (and therefore able to vote), but if you cannot attend, your nomination email will be read out before the voting begins." James went on to explain:

"It's really just a represent the community type of role. The LF uses the TAB to get a sense of the community for various things they and their members are thinking. Conversely, the TAB was initially formed to get a set of specific objectives out of the then OSDL (Doc Fellowship, Travel Fund, NDA programme and HW lending library plus a few other things). The TAB takes proposals from the community for things it needs that require an organisation to sort out (a good example of this is the currently being acted on PCI sig membership, which will give us access to the PCI specs plus a vendor ID that the virtualisation people asked for to help with virtual device recognition)."

Ingo Molnar announced version 20 of his Completely Fair Scheduler patchset, offering further cleanups for the new scheduler code that will be part of the upcoming 2.6.23 kernel, "there have been lots of small regression fixes, speedups, debug enhancements and tidy-ups - many of which can be user-visible." Ingo went on to summarize:

"There are nearly 100 changes - they do add up to a significant total linecount change. There was no crash bug or hang bug found in the CFS code since v19 was released. (in fact the last crash/hang bug in CFS was found and fixed in v7, more than 3 months ago, and even that crash only happened in an uncommon sw-suspend setup, not during normal use. So CFS has turned out to be a pretty robust codebase.) Nevertheless, if you had any problems (performance or behavioral) with v19 it's worth checking v20 out - and if v19 worked great for you it's worth checking out that v20 still works great =B-)"

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)."

"BACK UP ANY IMPORTANT DATA," began the Linux 0.10 installation instructions. "Linux accesses your hardware directly, and if your hardware differs from mine, you could be in for a nasty surprise. Doublecheck that your hardware is compatible: AT style harddisk, VGA controller." The installation guide explained that there were five major steps in getting Linux installed and running on your computer, including the above first step of backing up the system. The second step was to use Minix and the mkfs command to create a new filesystem on an empty partition of your hard drive. Third you used dd to write the 'boot' and 'root' Linux disk images to floppy disks. The fourth step was actually booting from the floppies, "having a floppy as root-device isn't very fast (especially on a machine with less than 6MB total ram -> small buffer cache), but it works (I hope)." The final step was mounting the empty hard disk partition, copying the files from the floppy disks to the partition, and creating the necessary /dev files with mknod, "you should now have a filesystem you [can] boot from. Play around a bit, try to get acquainted with the new system. Log out when you've had enough." The document noted that while it was possible to install Linux using DOS, the instructions were intended for people using Minix:

"In general, this version is still meant for people with minix: they are more used to the system, and can do some things that DOS-based persons cannot. If you have only DOS, expect some troubles. As the version number suggests, this is still not the final product."

Ingo Molnar pushed a series of patches to his Completely Fair Scheduler code upstream that were merged into the mainline kernel. He explained the reason for so many small patches, "the main reason is the safe and gradual elimination of a widely used 64-bit function argument: the 64-bit 'now' timestamp." In addition to the many small patches removing the 64-bit "now" timestamp, he noted:

"These changes are necessary for 3 reasons: firstly they address the 'there's too much 64-bit stuff in the scheduler' observation. Secondly, it's not directly visible but these changes also act as a correctness fix for an obscure (and minor) but not-too-pretty-to-fix accounting bug: idle_balance() had its own internal notion of 'now', separate from that of schedule(). Thirdly, this debloats sched.o quite significantly."

Following a recent merge request, Linus Torvalds stressed that he was serious about not wanting to merge any big changes after the merge window closes, "get the changes in before -rc1, or just *wait*. If they aren't ready before the merge window opens, they simply shouldn't be merged at all." Jeff Garzik reiterated, "once -rc1 is out there, that means the focus should be on stabilizing the existing codebase. Pushing a big driver update means that effort must restart from scratch. We just don't want to go down that road, which a big reason for the merge window in general." Further when it was noted that the recent changes were heavily tested by the vendor, Jeff stressed the importance of community testing:

"Take a lesson from when I was on Linus's shit-list... twice: Twice, Intel submitted an e1000 update after the merge window closed. Twice, they claimed the driver passed their quite-exhaustive internal testing. And twice, the most popular network driver broke for large masses of users because I took a hardware vendor's word on testing rather than rely on the testing PROVEN to flush out problems: public linux kernel testing.

"I'm not singling out Intel, there are plenty of other hardware vendors that repeat the exact same pattern."

Nick Piggin used 'git bisect' to track a lmbench regression to the main CFS commit, leading to an interesting discussion between Nick and Ingo Molnar. Ultimately the regression was tracked down to the temporary configurability of the scheduler while it is tuned for optimal performance, "one reason for the extra overhead is the current tunability of CFS, but that is not fundamental, it's caused by the many knobs that CFS has at the moment." The solution, already coded but not yet merged in the mainline kernel "changes those knobs to constants, allowing the compiler to optimize the math better and reduce code size," and as a result result, "CFS can be faster at micro-context-switching than 2.6.22."

Ingo described the lmbench configuration in question as a "micro-benchmark", and noted that with a macro-benchmark better performance was more pronounced, "because with CFS the _quality_ of scheduling decisions has increased. So even if we had increased micro-costs (which we wont have once the current tuning period is over and we cast the CFS parameters into constants), the quality of macro-scheduling can offset that, and not only on the desktop!" He summarized, "that's why our main focus in CFS was on the macro-properties of scheduling _first_, and then the micro-properties are adjusted to the macro-constraints as a second layer."

"So I tried to hold people to the merge window," Linus Torvalds began in announcing the 2.6.23-rc2 kernel, "and said no to a few pull requests, but this whole '-rc2 is the new -rc1' thing is a disease, and not only is -rc2 late, it's bigger than it should be. Oh, well." He noted that over 250 people contributed patches between -rc1 and -rc2, adding:

"A lot of the changes are small, and a lot of them really are fixes, but there's a MIPS merge in there too, and some absolutely _huge_ diffs due to some drivers undergoing Lindent cleanups (28 _thousand_ lines changes in advansys.c, and the PNP files got Lindented too, although those weren't nearly as big).

"But if you ignore the Lindent changes, the MIPS merge, the lguest documentation updates, and the MPT fusion driver changes, and the removal of the broken arm26 support, the rest of the changes really aren't that big."