Re: Compiling C++ modules

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux