| |||||||||||||
libabc: a demonstration library for kernel developerslibabc: a demonstration library for kernel developersPosted Nov 3, 2011 21:24 UTC (Thu) by alan (subscriber, #4018)In reply to: libabc: a demonstration library for kernel developers by andresfreund Parent article: libabc: a demonstration library for kernel developers
Tone aside, putting out an example library and a best practises document provoked this conversation on the topic at the very least, and thus has value. I wouldn't go so far as to want to attack Lennart & Co for their efforts, and even the tone of this particular message isn't too far off from an imperative standards document. However when you have built a reputation for being disagreeable it tends to color further communications.
(Log in to post comments)
libabc: a demonstration library for kernel developers Posted Nov 4, 2011 0:40 UTC (Fri) by wahern (subscriber, #37304) [Link]
It's all for naught. The coding style in the Linux kernel is horrendous. For one thing, they have their names backwards. In the Linux kernel (and often older GNU projects) it's common to write do_foo_to_bar(). In other words, verb, object, subject, plus often a superfluous literal "do". Best practice in userland is bar_foo_do()--subject, object, verb--or maybe bar_dofoo--subject, verb, object.
Linux kernel code is extremely difficult to follow because the horrible naming conventions mean that it's quite difficult to spot related code across the tree. Also, symbol names are often too literal, which is similar to writing superfluous comments--it's tells you what it's doing, but not why. In other words, kernel folks are helluva lazy. This isn't going to change, and neither will the quality of Linux kernel developer libraries. It's the culture, for better or worse. (I think worse, but the end product is still pretty nice.)
Interestingly, BSD kernel folks tend to be much better in this regard. Groking a *BSD kernel is insanely easier. And that goes even for bleeding edge features. The code for the feature is usually much more well structured. There's a strong correlation between how well a feature is modeled conceptually and how regular and sane the symbol names.
There's a difference between pretty and useful, of course. But for what it's worth, BSD code is definitely prettier.
libabc: a demonstration library for kernel developers Posted Nov 4, 2011 2:32 UTC (Fri) by sfeam (subscriber, #2841) [Link]
"it's common to write do_foo_to_bar(). In other words, verb, object, subject"
I suppose it's pointless to note that this is really [implicit subject], verb, direct object, indirect object. In other words, normal English sentence order. As in
Anyhow, that's a strange definition of "coding style".
libabc: a demonstration library for kernel developers Posted Nov 4, 2011 3:02 UTC (Fri) by cpeterso (guest, #305) [Link] const char *response = troll_feed(&food); (void)response;
libabc: a demonstration library for kernel developers Posted Nov 4, 2011 18:54 UTC (Fri) by dpquigl (subscriber, #52852) [Link]
Maybe it is because I first learned kernel coding with Linux but I find that to be the exact opposite. I had a much harder time figuring out BSD and OpenSolaris kernel code for my NFS work than I did with the Linux NFS implementation. In terms of coding style I often run into projects that I wish had the same coding style as the kernel. The code is formatted in a way that is easy to read. The size of functions are mostly pretty easy to handle. The organization of the code in the tree's hierarchy makes sense. The layering in the kernel is handled pretty well. It may just be a case of familiarity since I've been working on Linux for so long but I had a hard time with other unix operating systems.
libabc: a demonstration library for kernel developers Posted Nov 5, 2011 11:25 UTC (Sat) by adobriyan (guest, #30858) [Link]
do_*() functions are clustered near system call entry points and signal an entry to non-arch specific code.
Oh, and there is do_div(). :-)
libabc: a demonstration library for kernel developers Posted Nov 6, 2011 3:00 UTC (Sun) by butlerm (subscriber, #13312) [Link]
>In other words, kernel folks are helluva lazy. This isn't going to change, and neither will the quality of Linux kernel developer libraries. It's the culture, for better or worse.
And this is why the Linux kernel is deployed on three orders of magnitude more devices than *BSD kernels are? Laziness?
libabc: a demonstration library for kernel developers Posted Nov 6, 2011 6:16 UTC (Sun) by nybble41 (subscriber, #55106) [Link]
Of course. Everyone knows that smart programmers who are also lazy write better code; after all, low-quality code means more maintenance and debugging work down the road. It's the short-sighted ones you have to look out for. I don't think anyone would argue that the kernel developers are lacking in either intelligence or vision, ergo in their case laziness is definitely a virtue.
|
|||||||||||||