Re: C++ and the kernel (fwd)

[Dmitry A. Fedorov]

On Tue, 9 Apr 2002, T. A. wrote:

>     I am in the initial stages of writing some C++ wrapper classes for the

At first, look this:
http://www.inp.nsk.su/~fedorov/export/linux-cxx-test-1.20.tar.gz

Yes, it is possible to write kernel modules in C++ and I do,
but it does not have much sense to use wrappers. Use classes only
for complex data structures, lock and so forth.

> kernel.  So far its been an interesting process, mainly due to the use of
> some C++ keywords in the kernel header files.  Mostly gratuitous at that as

There are many issues with C++ and kernel and keywords problem is
least significant and easy solved without of any kernel patching.

>     So far my overloading of "new" works if I compile the module without
> exceptions (-fno-exceptions).  This is fine for myself as I prefer checking
[...]
> object file.  Does someone know how I can resolve this?

Don't use C++ exceptions at all until you resolve all of problems
concerned with them.

> limitation in how gcc's "alias" feature is used.  Apparently for C++ one
> must pass the mangled name of the function in question.  Is there a gcc
> macro or function of some kind to do something like this:

Don't use wrapper classes and the problem is not appeared at all.
Any of C++ kernel modules must have both C and C++ sources.

> int init_module() __attribute__((alias(mangle_name("load__9my_module"))));

There are many places with sources of demangling flying around,
but mangling sources is only in one place - g++ :(
And note, that default mangling algorithm of g++ is changed
periodically. So, forget about it.

>     Another issue that I currently have is that I haven't been able to
> figure out a way to get the module to properly initiate global objects.
[...]
> Anyone know how I can get gcc to insert the global initiation
> code from within init_module?

Look at my sources, linux/cxx/xtors* and the cxx-test module's 
Makefile

>     So far C++'s use of the kernel headers has found a couple of areas in
> which possible bugs exists.  In one header file the typedef ssize_t is used
> despite its definition not appearing in the source file or any of the
> included header files.  I've also encountered negative numbers being
> assigned to unsigned numbers without a cast.

Yes, kernel code is pretty inaccurate is such relation.
I have use most strict g++ warning options to reduce probability of
some bugs in my code. Use 'STRICT=y make config' command to swith
these options on.

To prevent flooding by warnings from kernel headers, I have local
patches:
http://www.inp.nsk.su/~fedorov/export/linux-warning-cleaned-headers-1.9.tar.gz
which are not supplied to customers.

--