We need to use those extensions
> Even if the kernel itself is forever joined at the hip to gcc-2.7.2, it
> would be only civilized to arrange for the headers to be legal ANSI. Many of
Why ? Certainly glibc should be exporting highly clean and legal ANSI headers
to applications, but kernel space happens to need __inline__ and __asm__
and the like. egcs understands these and also gcc calling conventions.
The problem with g++ modules are actually two fold. The first is that g++
has ideas about things like private, new and other quite sane (to C programmers)
normal variable names being keywords). The second one is that it wants to
use new and destroy. You can provide your own new/destroy wrappers using
the kmalloc/kfree functions although you have to be careful to handle failure
cases. The conventional C++ "out of memory" message and quit wont cut it in
a kernel.
There are side issues - stack usage is hard to track in much C++ code, g++ used
at least to have terrible problems remembering about volatile and you can't
expect stuff like exceptions to work.
Fixing the use of "private" -> "priv" and similar in the kernel is eminiently
reasonable. Trying to write kernel code with another compiler is going to give
you a very bad headache. AFAIK the only folks who did it were the linux 8086
people and even then it was non trivial - thats not even a port but an offshoot
of a subset of the kernel code.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/