Quotes of the week [LWN.net]

The number of contributors who can write meaningful changelogs or who can be taught to write really good changelogs is very, very low. I'd guesstimate somewhere around 5% of all Linux contributors. (The guesstimation is probably on the more generous side.)

-- Ingo Molnar

No subject should ever contain the word "trivial". If it's really trivial, you can sum it up in the subject and we'll know it's trivial. Plus the diffstat shows it. 'trivial' is propaganda to sneak a patch into -rc7.

-- Rusty Russell

In the past 15 years of Linux we've invested a lot of time and effort into working around and dealing with compiler crap. We wasted a lot of opportunities waiting years for sane compiler features to show up. We might as well have invested that effort into building our own compiler and could stop bothering about externalities.

-- Ingo Molnar

to post comments

Kernel compiler

Posted Apr 23, 2009 17:08 UTC (Thu) by xav (guest, #18536) [Link] (4 responses)

Even if it seems like a huge task, the kernel guys already made a complete distributed SCM, a task which was believed too big. So they probably can do it, especially if they start from something like LLVM.

The problem is that the kernel will tend to be written into its own dialect of C, and using another compiler (e.g. for some obscure embedded achitecture) will be near impossible.

Kernel compiler

Posted Apr 24, 2009 6:52 UTC (Fri) by man_ls (guest, #15091) [Link] (3 responses)

A distributed SCM is a more-or-less closed task since it has to support only a particular flow. But git has been intentionally kept very open, and as a result it is so flexible that it can scale to very different situations. Could it be done with a compiler?

On the other hand, a compiler is a moving target. Computer languages (similarly to human languages) evolve with time: new features creep in, old features get deprecated all the time. Short term, the effect of writing a compiler would be as you say to make it specific to the kernel dialect. But long term it would be 100 times more pernicious: it would fixate the kernel dialect and make any evolution nearly impossible by sheer inertia. In a few years (say, another 20) all kernel code would look so old and crusty that people would probably want to stay away.

Conflict (of the kind that Ingo speaks about) is what makes languages evolve. It would probably be possible to write a generic compiler and let the specifics of kernel code for a different tool like checkpatch.pl, but the task would be much more complex than writing a distributed SCM. I am guessing GCC-like complex. The interaction between kernel developers and GCC hackers may be fastidious, but it is beneficial long term.

Kernel compiler

Posted Apr 24, 2009 12:38 UTC (Fri) by error27 (subscriber, #8346) [Link] (2 responses)

"kernel code would look so old and crusty that people would probably want to stay away."

The kernel already has code so crusty that people stay away from it. :P

My view is that tying the kernel and sparse would probably lead to more sparse mark-up. There is more error checking that could be done. Using sparse would lead to more change, and more flexibility, not less.

For example, you could mark some functions as user context only, and the compiler could catch it compile time if you called them from irq context.

Kernel compiler

Posted Apr 24, 2009 16:06 UTC (Fri) by man_ls (guest, #15091) [Link]

I agree with you: an auxiliary tool like sparse would be a win for everyone. Please correct me if I'm wrong, but this way the kernel is not tied to the compiler (the syntax) but to an additional layer which adds semantics.

Kernel compiler

Posted Apr 24, 2009 18:48 UTC (Fri) by viro (subscriber, #7872) [Link]

Not only can, but most likely will; the main issue with function annotations right now is that we still have rather messy type system implementation on the sparse side. It *is* getting better and that kind of stuff (function classes, annotations, work with call graph, etc.) is very much a part of goals. Secondary problem is that we'll need a bit more work on linearizer, but it's less painful.

However, that's not related to having sparse in the kernel tree (to be honest, I do not think it's a serious issue either way - sparse lives in another repo on kernel.org, after all; OK, 3 repos, but that's a separate
story).

What's much more important, and completely missed in all that discussion is that sparse uses for analysis, typechecking, etc. and sparse use as filter that would feed gcc are very, very different animals. Once you've got to parser, you lose the ability to do pretty-print-to-C. And most of the useful things can't be done without parsing. Use of modified preprocessor to extend C is a way to really lousy language; the interesting stuff lives at phase 7 and after it.

So it's either "forget about gcc, have generating *.s by sparse mandatory", which requires backend for all targets or it's "sparse used for extra analysis, in addition to some C compiler and with input files for sparse being acceptable for the latter".

_That_ is the hole in Ingo's "we could use sparse to replace gcc" handwaving. And AFAICS it's not pluggable. I wouldn't mind seeing other compilers and I certainly expect more sparse _annotations_ in the kernel, but sparse-as-kernel-compiler-instead-of-gcc really, honestly will require full set of backends for all kernel targets. Plus a lot of work on data flow analysis, etc.

Quotes of the week

Posted Apr 23, 2009 20:19 UTC (Thu) by anton (subscriber, #25547) [Link] (3 responses)

It's not just the kernel people that is wasting a lot of effort on working around GCC crap, it's also the application people; actually I believe that the kernel people are better off than many application people because the kernel is high-profile enough that the GCC people are at least a little reluctant breaking it, whereas they don't give a damn about most applications. So I would love to see a decent alternative to GCC. Then we could leave the GCC people to concentrating on their main purpose: compiling the SPEC benchmarks.

Quotes of the week

Posted Apr 23, 2009 20:30 UTC (Thu) by docwhat (guest, #40373) [Link] (2 responses)

And don't get me started on the trainwreck that is autoconf/libtool.

Quotes of the week

Posted Apr 24, 2009 17:04 UTC (Fri) by alfille (subscriber, #1631) [Link] (1 responses)

>> And don't get me started on the trainwreck that is autoconf/libtool.

Speaking of old crusty code that no one wants to touch. Unfortunately it's very much like debt -- hard to extricate yourself.

Debt

Posted Apr 29, 2009 21:52 UTC (Wed) by roelofs (guest, #2599) [Link]

Speaking of old crusty code that no one wants to touch. Unfortunately it's very much like debt -- hard to extricate yourself.

...which is precisely why one of the current buzz-phrases is technical debt.

Greg

Quotes of the week

Posted Apr 30, 2009 7:27 UTC (Thu) by DarthCthulhu (guest, #50384) [Link] (1 responses)

I'm surprised no one mentioned Clang (http://clang.llvm.org/), the LLVM-inspired C-language compiler.

It compiles C code right now and some C++. It would need a bit more work to compile Linux kernel code, due to all the GCC cruft caked in it, but if the kernel guys made an effort, it could probably be done in a few release cycles.

Quotes of the week

Posted May 1, 2009 2:43 UTC (Fri) by jgarzik (guest, #8364) [Link]

This meta-bug shows what is needed to compile the kernel under clang+LLVM.

The LLVM guys have already closed a bunch of kernel-related bugs (Bugzilla: "show dependency tree" -> "show resolved" button).