Messages in this thread | | | From | Michael Buesch <> | Subject | Re: Compiling C++ modules | Date | Tue, 25 Apr 2006 21:54:08 +0200 |
| |
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. [unhandled content-type:application/pgp-signature] | |