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.