Re: Compiling C++ modules

[Avi Kivity <avi@argo.co.il>]

Willy Tarreau wrote:
> It would be the exact same problem I discribed above. If nobody understand
> what it does, or if people need some deep thoughts to guess its behaviour,
> the result will be negative. Currently, everyone can read the kernel code.
> I was a terrible looser in C 11 years ago when I first looked at it, but I
> did not need specific knowledge of implicit things that the kernel does to
> understand what the code did, and to propose patches.
>
>   

11 years ago the kernel was _way_ simpler.

These days, you need to know that you can't call schedule() (or any 
function which may sleep -- why is that not implicit) within spin locks. 
You need to understand per-cpu variables, initcalls, rcu, memory 
barriers, reference counting, and lots of other "infrastructure" details 
that are engraved into your brain but not accessible to a newbie. Most 
of these (except perhaps reference counting) cannot be understood from 
looking at the code.

C++ allows you to add even more infrastructure, by providing support for 
patterns that can't be done in C. So yes, that adds more to the 
vocabulary you have to learn by heart but once you're over that the code 
is _more_ readable, more maintainable.

> Right now, lots of newbies review the code and find bugs. If you write it
> in a language such as above, it will quickly end up like the BSD kernels,
> with a small very competent core team and lots of newbies around them.
>
>   

C++ knowledge is now fairly widespread, I believe.

> I don't know, what I can say is that they were people who regularly discuss
> the kernel semantics on other threads. That's what matters. Those people are
> good at finding kernel bugs and proposing interesting algorithms, it's a shame
> that they had to discuss langage semantics on 5 lines of code !
>   

I'm sorry to have wasted their time. But surely you understand these 
things once and then move on? Like when someone proposes a new function 
to replace repeated code, there's argument about it's name, coding 
style, and hopefully about the content. The people replace the 
open-coded sequence with the new function.

It's the same here at a slightly higher level. You argue what s spinlock 
guard should look like, whether it's optimal or not, and then you can 
use it where applicable and avoid those gotos or code duplications for 
error cases.

 

>
> I seems like pro-C++ people constantly tell the other ones "look, C++ can
> code for you so that you won't have to worry about boring parts. Of coure,
> if you need to know, you're still able to write is the old way". Since we
> always want to know, I guess we'd use the C++ compiler (the slow one), with
> pure-C code borrowing nothing from the C++ language. That would only be a
> pure loss.
>   

It's not "if you need to know", it's "if you want to break the rules".

For example, the spinlock guard thingie allows you to say, "please 
spin_unlock this spinlock for me, whichever way I return from this 
function". There is no knowledge taken away, you know exactly what it 
will do and when; only the code is made clearer.

But if you want the function to lock but not unlock, or do the 
atomic_dec_and_lock() thing, or do lock reordering to avoid ABBA 
deadlocks, or whatever, the primitives are still there.

These constructs allow you to make simple things simple (and automatic) 
but don't take away the complex things.

(example, for context:

{
    spinlock_guard guard(some_lock);
    if (x)
        return -ESOMETHING;
    blah();
    return 0;
}   

there is nothing implicit once you know spinlock_guard)


>> No, they want not to repeat code and code patterns. It's the same 
>> motivation that lead to the invention of functions:
>>
>> - functions allow you to reuse code instead of open-coding common 
>> sequences
>> - constructors/destructors allow you to reuse the do/undo (lock/unlock, 
>> etc.) pattern without writing it in full every time
>> - templates allow you to reuse code even when the data types change 
>> (like the preprocessor but not limited to linked lists)
>> - virtual functions allow you to dispatch a function based on the 
>> object's type, without writing the boilerplate casting
>> - exceptions allow you to do the detect error/undo partial 
>> modifications/propagate error thing without blowing up the code by a 
>> factor of five
>>
>> It's just shorthand: but shorthand allows you to see what the code is 
>> doing instead of how it handles all the standard problems that occur 
>> again and again in programming.
>>     
>
> I'm still not convinced. Every time I came across C++ code, it was an immense
> unreadable crap (indentation, cAmEl case, "funny" operators which you have to
> stop at because you need a few seconds of thought before confusing them with
> others, etc...). Code that cannot be read at 3am. If you want a good example
> of this, download and read p7zip. It does lots of magic^Wimplicit things which
> quickly got me lost. I agree, I'm not a C++ developper. But many language are
> slightly understandable to non-fellows, and this one looks really nasty.
>   

I agree - I've seen it done many times. C++ has the potential for a lot 
of nastiness, and what is more, it seems to bring out the worst in 
people. We would definitely need an Al Viro for C++ if the kernel were 
to be ported.

I've yet to find a language that combines low level access, efficiency, 
cleanliness, and expressive power.

> You told us examples of programs you have written. If this is true, I have
> a lot of respect for this, because it still seems impossible to me. I
> understand they were closed source, but if you come across open source
> kernel code that is readable by newbies, I think many people would be
> interested to get a clue.
>   

I posted an example of do_sendfile() as it might be incrementally converted.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.