C++ and the kernel

Hi all,

I am in the initial stages of writing some C++ wrapper classes for the
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 most of the C++ keyword uses I've encountered so far are the use of the keyword "new" as variable names in some inlined functions. Well I've fixed up the header files (I've used so far) and have been able to successfully overload the new and delete keywords thus allowing me to properly construct and deconstruct C++ objects within a kernel module. Well I've encountered a couple of issues I hope someone can help me here.

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 for a NULL on a memory allocation error over handling an exception, plus the resulting code appears to be much more efficient without exceptions by a large order of magnitude. However I would like my C++ kernel support to include exception support if possible so those whom may want to use it, besides which it may yet prove itself useful. However allowing exceptions in (if used apparently, via so far my overloading of "new") appears to put an undefined reference to throw and (I think) terminate into the resulting object file. Does someone know how I can resolve this?

I would like to add the ability for the wrapper classes' users to use
static member functions as the module initiation and cleanup functions. For example:

class my_module

{
    public:
        static int load();
        static void unload();
};

And use my_module::load() as the init_module function and
my_module::unload() as the cleanup_module function. The provided macros module_init and module_exit should do this for me however I've encountered a 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:

int init_module() __attribute__((alias(mangle_name("load__9my_module")))); int cleanup_module() __attribute__((alias(mangle_name("unload__9my_module"))));

I need a function or macro like mangle_name above.

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. Like so:

my_module mod1;

If I put this in the source file as a global function and load the
module, I've found that this module's constructor doesn't get called. I figured out why and gcc's documentation backed me up. However I can't seam to find any way to tell gcc to initiate the object file's global objects from within the init_module function. I know a workaround would be to have a pointer instead and allocate the object in init_module however I think its best to avoid pointers whenever possible to reduce the chance of errors. Anyone know how I can get gcc to insert the global initiation code from within init_module?

On a side note:

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. And I've found completely unnecessary use of the C++ keyword "new" as variable names in some inlined functions.

Would patches be welcomed for one or more of these issues?

Thanks.

This will turn out to be nearly impossible. Please note that
the exception mechanisms in C++ are basically a second function return path and are therefore not desirable at all for the following reasons:

1. It's silly becouse we have already a return path and page fault based exception mechanisms in kernel, which is far better suited for the purposes of the kernel then the C++ semantics. (Remarkable the KDE people recognize that C++ exceptions are not a good thing...)

2. It's changing the stack layout for the kernel functions, and there are few of them which rely on a particular stack layout (namely the scheduler and some *.S files - look out for the asmlinkage attribute...)

Yes I know - PLEASE JUST FORGET ABOUT IT.

I guess the above wouldn't work due to the games which the linkage scripts play already on the init_module and cleanup_module function. Maybe you would rather wan't to have a look at those scripts themself and adjust them accordingly? (Possibly having a mangling tool at hand...)

Well the "hidden C++" initializations you should propably forget about - they are not desirable inside the kernel, becouse this C++ mechanism is annihilating the expliciticity of the programm controll flow of C.

Personally I would just like to have the ability to compile the kernel with C++ just for the following two reaons:

1. C++ is a bit tighter on type checking, which would give better regreesions.

2. Modern GCC versions generate generally better code for C if compiled as C++ files, since the language gives tighter semantics to some constructs.

However I wouldn't for certainly like to see the kernel beeing transformed in to C++. Expierence has shown over time that the chances for abuse of this programming language are just too high. Language design idiocies like the following come immediately in to mind:

1. Templates.

2. Runtime Type Information.

3. Operator overloading. This makes the language morphable which is killing nearly the ability to understand code by reading it.

4. Syntactically hidden code paths
(exceptions, constructors with side effects, destructors which you never know when they tis you...) make the readability even worser...

5. Instability of compiler implementations (ever wondered how many libstdc++ you have on your linux system?)

I would like to rewrite the kernel in FORTRAN because this was one of the first languages I learned.

Seriously, the kernel MUST be written in a procedural language. It is the mechanism by which something is accomplished that defines an operating system kernel.

C++ is an object-oriented language, in fact the opposite of a procedural language. It is not suitable.

Many so-called programmers look at kernel code and see that a lot is written in 'C'. Then they think; "I can do this better because I know C++. Everybody knows that C++ is better than plain old C..."

If you really knew C++, you wouldn't even joke about putting it in the kernel.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).

Windows-2000/Professional isn't.

Who the heck said anything about rewriting the kernel? I'm just looking
into coding a C++ framework for those whom may like to use it in modules, mostly for hack value.

And yes I do know C++ and it can very well be used for low level stuff
such as the kernel. Now that doesn't mean I'm going to go wild and start writing extensive templates, exceptions, standard template libraries, or any of the other unneeded crap (mostly from the last C++ revision) either.

And as far as the comment of being a troll goes I could definitely find
better uses of my time. Only reason for a post here is because I'm looking for some guidance on a couple of minor issues I've encountered. The C brigades can go back and rest in the barracks now.

----- Original Message -----
From: "Richard B. Johnson" <[email protected]>
To: "Martin Dalecki" <[email protected]>
Cc: "T. A." <[email protected]>; "Linux Kernel Mailing List" <[email protected]>
Sent: Tuesday, April 09, 2002 8:10 AM
Subject: Re: C++ and the kernel

----- Original Message -----
From: "Kurt Wall" <[email protected]>
To: "T. A." <[email protected]>
Sent: Tuesday, April 09, 2002 12:16 PM
Subject: Re: C++ and the kernel

the

of

From: "T. A." <[email protected]>

May I humbly suggest that this list is not a good place for this discussion. Attitudes are quite ossified for many good reasons and probably a few bad reasons. Take a reasonably cleanly functioning kernel as a tool and develop a fully C++ kernel. Try it out. Benchmark it for size and speed. Report back comparisons with its original base.

You are sounding like a little boy who has found a new toy. Over 40 years of experience suggests the proper way to handle this is to let the person have his head, and in the corporate world some IR&D funds, to develop a project that uses the idea and report back in detail how it worked out. If it succeeds the company or group wins. If it fails it managed to stay out of your product stream, for as sure as the Sun generally rises roughly in the East it WILL find its way into something as the person's way of finding out for himself if it works.

This is an issue that has caused this list a significant amount of distraction over the years. Maybe it would be a really good thing to develop numbers and data to either support it or shoot it down. The cant of a Computer Science cirrocumuli often fails when the rubber meets the road. This may and may not be such. I trust the kernel maintainers' instincts in this regard. Old age and experience will beat youth and enthusiasm any day in the long run.

So take a team with you, select a dictator or leader or whatever, and simply make a rigid translation of a kernel snapshot to C++ without adding any new functionality. Let us all watch the progress, say on SourceForge or the like. And report back when it is all done. You may be right that it is something that is worth doing. But, unless you can show in very hard data that there is a real advantage to C++ in the kernel Linus will simply reject it with the full support of the rest of his crew.

FWIW, Microsoft does not use C++ in their kernel.
{^_^}

I hate to get into this discussion(1)... but could you at least read a little bit beyond the subject line before answering. The bits like "who that heck said anything about rewriting the kernel?" and "hack value"...

Rui Sousa

(1) Yeah, ok I did it any way.

Bollox!

There are many places in the kernel that are actually very OO - look at filesystems for example. The super_operations sturcture is in effect a virtual function table.

Sure making every file an object is probably OTT; but large scale things like a filesystem, a network device or the like probably actually fit very well.

Sure, there are a lot of features of C++ to stay clear of - exception handling probably being one of them, and I wouldn't let the C++ stuff anywhere near the memory management code.

Point being that it is a case of using the write tool for the job. C++ douesn't add any extra overhead just by calling it C++ and not using any of the features; careful use of the features where appropriate does no harm and might actually make the code cleaner, and possibly more efficient.

I will agree going head in and just throwing C++ at it is a bad thing.

Dave

---------------- Have a happy GNU millennium! ----------------------

/ Dr. David Alan Gilbert    | Running GNU/Linux on Alpha,68K| Happy  \ 
\ gro.gilbert @ treblig.org | MIPS,x86,ARM, SPARC and HP-PA | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/

The file operations structure(s) are structures. They are not object- oriented in any way, and they are certainly not virtual. The code that manipulates them is quite physical and procedural, well defined, and visible to the rest of the kernel.

Err. From the outside-in, any well-defined software functionality can look like an "object". In fact, any well-defined and well functioning software is indistinguishable from magic, therefore can be represented as an object in the true object-oriented sense.

C++ is designed for user-mode programming. It expects to interface with a complete operating system with well-defined characteristics. It is not designed to be part of an operating system kernel.

It is quite unlikely that a C++ compiler will make more efficient code than a C compiler. In fact, the code generator will likely be the same. The C++ compiler will end up generating some preamble code as part of the function-calling mechanism, that is not necessary in C. This means that it will generate a bit more code.

Making code "cleaner" is a matter of perspective.

	class A {
        public: void func(char *st) { cout << st << endl; }
        };
        using A::func;
        A a;
        a.func("Hello World!");

Is not all that clean. In fact, I'm not sure I have it right. It's easier and clearer to write puts("Hello World!");

Cheers,
Dick Johnson

Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).

Windows-2000/Professional isn't.

I disagree. A filesystem has a certain set of semantics. There are numerous types of filesystems, each of which implements that set of semantics (and possibly additional ones as well) in a different way. This is a classic example of a situation where oo style programming can be useful. There are many cases where C code is in essence implementing virtual functions using function pointers. C++ allows the compiler to do the hard work of keeping track of the virtual functions.

C++ has tigher constraints on code than C. This can allow a compiler to generate better code because it has more knowledge about what is going on.

Your example is needlessly complex, and I'm sure you know this. A more realistic comparison would be:

cout << "Hello World!\n";

Now I don't for a moment think that we should go and convert everything to C++. But I do think that certain features of the language can be useful, and that there are cases when OO style programming makes the code easier to read and understand.

Chris Friesen                    | MailStop: 043/33/F10  
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: [email protected]

commence Chris Friesen quotation:

And of course standard libraries are not available in the kernel, so you'll most likely end up calling printk anyway in your C++ kernel code.

 /////////////////  |                  | The spark of a pin
<[email protected]> |  (require 'gnu)  | dropping, falling feather-like.
 \\\\\\\\\\\\\\\\\  |                  | There is too much noise.

On Tue, 9 Apr 2002, Sean Neakums wrote:

[snip]

Guys, take it somewhere else. See l-k FAQ for reasons.

Not according to Apple.

http://developer.apple.com/techpubs/macosx/Darwin/IOKit/iokit.html

"The I/O Kit is a collection of system frameworks, libraries, tools, and other resources for creating device drivers in Mac OS X. It is based on an object-oriented programming model implemented in a restricted form of C++ that omits features unsuitable for use within a multithreaded kernel."

Although I wouldn't use this as a justification for doing this in Linux ;).

~mc

As Alan said it very nicely one day:

"Object orientation is in the mind, not in the compiler"

What we want is some (sane) degree of abstraction so things stay maintainable, we don't need a full rewrite in another language.

regards,

Rik

Will hack the VM for food.

http://www.surriel.com/		http://distro.conectiva.com/

Followup to:  <[email protected]>
By author:    "Richard B. Johnson" <[email protected]>
In newsgroup: linux.dev.kernel

Again, bollocks. The file operation structures are vanilla vtbl implementations of virtual functions. The fact that they're written

foo->f_ops->func(foo, ...);

instead of

foo->func(...);

makes absolutely no difference whatsoever.

-hpa

<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<[email protected]>

[snip]

No. See http://www.tux.org/lkml/#s15-3 .

Erik

J.A.K. (Erik) Mouw, Information and Communication Theory Group, Faculty
of Information Technology and Systems, Delft University of Technology,
PO BOX 5031, 2600 GA Delft, The Netherlands  Phone: +31-15-2783635
Fax: +31-15-2781843  Email: [email protected]
WWW: http://www-ict.its.tudelft.nl/~erik/

Scribbling feverishly on April 09, T. A. managed to emit:

Stop right here, read http://www.tux.org/lkml/#s15-3, and figure out what you've done wrong. ;-)

I dare say not. One wonders if this message was a carefully crafted troll.

Kurt

Ships are safe in harbor, but they were never meant to stay there.

----- Original Message -----
From: "Martin Dalecki" <[email protected]>
To: "T. A." <[email protected]>
Cc: "Linux Kernel Mailing List" <[email protected]>
Sent: Tuesday, April 09, 2002 5:54 AM
Subject: Re: C++ and the kernel

checking

reasons:

purposes

recognize

attribute...)

Well I don't really need (or like) exceptions so forgetting about them
works for me. However currently there is no other efficient means of determining if an error has occured during a objects construction. No return value. Would have to waste memory on a flag variable. Would the above problems also be present on the module level? I don't really want exceptions leaving the module, so to speak.

__attribute__((alias(mangle_name("load__9my_module"))));

Do you mean the module_[init|exit] macros? If so I've already taken a
look at them. Thats where I got the alias from. And the above does work. However currently I have to compile the module, do nm on it, find the magled name, and enter it manually as above; then recompile. Works though.

Oh well works for me. Pointers to objects will get the job done.

regreesions.

C++

this

killing

know

libstdc++ you

Don't worry, not looking to do a C++ rewrite. Just looking to be able
to setup a C++ framework for use in modules.