Go ahead and do it. Actually I suspect gawk will beat you or come very close.
Its virtually I/O bound and it beats gcc -M doing basically the same task.
> Interface lock for each version.
Ah locking in catastrophes. Bad. 1.2.x keeps the same internal interfaces
2.0.x should but not other things. The idea also doesnt work too well for
a kernel when things can change that are subtle and internal.
> 3. Use the features in C++ that will allow a more stable kernel
> Okay here is where i am going to get the developers mad at me. How about
> converting parts of linux to use C++, no not classes or the object
> oriented
> stuff, just the parts that can make life easier for the developer, and
> make
> the kernel run faster and more stable. Use default arguments, to
C++ code is currently slower and has buggier output than well written C (
especially as certain people bother to peek at the assembler output). Unless
the g++ walking volatile bug has finally been fixed its also not
usable. Finally g++ eats memory - forget building on an 8Mb machine with g++
> Also we could use C++ streams type functions to implement printk calls. I
> wonder how many drivers have been broken by stack corruption, by
> incorrect
> params in printk calls. Variable argument function calls are inherently
> slower then fixed argument calls.
But not than C++ calls or multiple calls or the other mess. I've not found
a single problem with printk, because gcc supports typechecking of printf's
Alan