An In-Kernel C Compiler?

Ingo Molnar suggested that the kernel should include its own source compiler inside the codebase itself, a tightly integrated Linux alternative to GCC that would eliminate the nightmare conflicts that have occasionally raged between the kernel developers and the GCC developers. If anyone less involved in kernel development than Ingo suggested something like this, I suspect it would be met with a high degree of skepticism. In fact, even with Ingo suggesting it, there was some of that.

His idea was to combine a precompiler, compiler, assembler, and linker into a single tool that would ship with the kernel sources and remain "in lockstep" with each other, avoiding not just the developer conflicts, but also a lot of jumping through hoops that the kernel currently must do to accommodate GCC. As a first step, the tool could simply perform pre-processing that would be fed to GCC. Then gradually more compiler functionality could be added. This, he said, would have an immediate benefit in terms of simplifying the kernel code.

Initially, there was some support for the idea. Steven Rostedt raised the issue, suggesting that Ingo's idea was a good one; then Ingo replied with this elaboration. And Anton Ertl pointed out that an alternative to GCC wouldn't just help the kernel get around GCC problems, it would help lots of user-space software as well. But he thought forking GCC as a starting point had some good arguments in its favor, including the ability to compile code for a wide variety of hardware architectures. David S. Miller pointed out that one drawback to writing a new compiler would be losing GCC's efficiency at doing preprocessing and compilation all within the same binary, instead of passing data through a pipe. He also didn't like Ingo's idea in general. Instead of working on a compiler, he thought people should focus on writing kernel code. He also thought the whole project would take a lot more time and effort than Ingo expected. Having written a compiler before, Eric W. Biederman also confirmed that it would take a really long time, but he thought Ingo's idea might be worthwhile if it would result in big advances in debugging and compiling speed.

Christoph Lameter also thought that something short of an actual compiler might be useful. Something that could get rid of all the complexities and special cases associated with current preprocessing would be a significant improvement, he said. Alexander Viro did not agree that the existing preprocessor situation was very complex, and he invited the folks involved in the thread to read the C standard [2], specifically Chapter 5 and section 6.10. At this point, the conversation petered out.

What will come of this discussion isn't clear, but it seems to have the attention of some powerful coders. Or what folks currently think of as deficiencies in GCC could end up being about the best they can hope for, but it's likely that someone will attempt to find out for sure, at least with regards to preprocessing.

Some Filesystem Tools Open Sourced by SGI

Greg Banks announced that SGI was releasing a number of pieces of software under the GNU General Public License, version 2. SGI wouldn't participate in supporting the software; in fact, some of the code was unfinished, and some was reliant on internal SGI development infrastructure that was not also being released. So this particular case doesn't appear to be an attempt to collaborate with the open source world as much as it is simply throwing code into the world and hoping someone finds it useful.

Among the released tools is checkstream, a tool that can automatically detect certain kinds of filesystem corruption. Another tool, weber, is designed to put a heavy load onto an NFS filesystem. In all, nine tools were released.

Laptop LED Alerts

Márton Németh has removed the "experimental" dependency from the leds-clevo-mail driver in the config file, which lets Clevo notebooks – specifically, models D410J, D410V, M540N, and M5x0V – control their mail LED. This is a cute thing to support, not necessarily with a wide audience, but it does bring Linux closer to seeming like the natural operating system to be running on any given piece of hardware. (Not that we don't all enjoy explaining to our non-Linux-savvy buddies, "This LED does nothing right now. Under Microsoft it would alert me whenever mail arrives.")