Re: Compiling C++ modules

Michael Buesch
2006-04-25T19:49:07Z

[-- Attachment #1: Type: text/plain, Size: 2029 bytes --]

On Tuesday 25 April 2006 21:22, you wrote:
> Except they can't. Lots and lots of bits of kernel code explicitly
> depend on the fact that certain operations _cannot_ fail, and they
> make that obvious through the fact that those functions don't have
> any way of returning error conditions.

A function declared as
void foo(int bar) throw();
cannot fail or throw.

> >> First of all, that extra TakeLock object chews up stack, at least
> >> 4 or 8 bytes of it, depending on your word size.
> >
> > No, it's optimized out. gcc notices that &lock doesn't change and
> > that 'l' never escapes the function.
>
> GCC does not notice that when you use out-of-line functions. Let me
> remind you that many of the kernel's spinlocks and other functions
> are out-of-line, inlining them has significant performance penalties.

The TakeLock object is completely different from the actual
lock object. The TakeLock object does _only_ call
spin_lock() and spin_unlock(), which are still out of line.

> {
> int result;
> struct foo *item = kmalloc(sizeof(*item), GFP_KERNEL);
> if (unlikely(!item))
> return ERR_PTR(-ENOMEM);
>
> spin_lock(&item_lock);
>
> result = item_init(item, GFP_KERNEL);

scheduling while atomic ;)

> (1) You can't easily allocate and initialize an object in 2
> different steps.

That is not true. Google for "d-pointer" for an example
on how you might do this.

> (2) Your code either adds a refcount for "item" or unconditionally
> releases it at the end of the function. Yes that's fixable, but not
> in a way that preserves the exception-handling properties you're
> espousing so much. When you get an exception, how does the code tell
> which objects to free and which ones not to?

By good design of the exception objects, which carry all needed
information when handling the exception.

I _don't- want to say, that C++ is good in the kernel.
My opinion is: C++ in the kernel is bad.

--
Greetings Michael.

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]