Kernel compiler [LWN.net]

Kernel compiler

Posted Apr 23, 2009 17:08 UTC (Thu) by xav (guest, #18536)
Parent article: Quotes of the week

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.

to post comments

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 (guest, #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.