There are actually two sets of headers here, which, unfortunately,
are overlaid on top of each other in Linux; the headers the
kernel needs can be rotten with __inline__, __asm__, and __magic
extension__ and it won't really matter. The headers userland
needs are the published interface, which can be sanitized into a
real language because they aren't likely to change very often.
The module interface isn't published, because it changes with the
phases of the moon, but if the rapture does happen and Linux does
get published module interfaces, a public set of headers wouldn't
be beyond the pale.
>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.
printf doesn't work too well in the kernel, either. If people
wrote modules in C++ (which seems perfectly feasable, though
overkill for most of the stuff one might want to modularise)
they'd figure out pretty quickly what things you can't do if
you want to make your module actually work.
____
david parsons \bi/ though C++ would be a virtual cornucopia of
\/ unexpected surprises.
-
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/