Theodore Y. Ts'o (tytso@MIT.EDU) writes:
> Date: Thu, 11 May 2000 13:18:44 -0500
> From: Ed Carp <erc@pobox.com>
>
> This sort of elitist attitude really irritates me. "I am the God of
> Whatever Driver, and Ye Shalt Come And Worship At My Feet". If
> kernel development isn't supposed to be easy, then I guess from that
> perspective Linus is a complete fraud and a wimp because he didn't
> write the base kernel in machine language. Kernel development is by
> no means a piece of cake, but it should be no harder than absolutely
> necessary.
>
> Kernel development should be supportive of new people coming in, not
> trying to shut them out.
Hi, Ted!
> ... and the attitude of people telling volunteers that they should be
> spending their precious time working on whatever the whiner is
> complaining about (whether it's kernel documentation, or half-duplex
> support, et. al), is just as irritating.....
I'm not telling anyone what to do - it's just that a bit of documentation
here and there (1) makes the code cleaner and easier to read, and (2) is a
lot more professional. When Linux was just Linus and a couple hundred of
his closest friends, it was OK, but now there are literally thousands of
people looking at the kernel and trying to figure it all out, and from the
perspective of Linux-going-commercial, it just doesn't give the air of
professionalism that one might hope to engender.
And while the approach of "if it works, screw it, ship it" may work in some
sweatshops, it's just bad coding practice to not document, at least enough
so that the next guy that comes behind you can hopefully understand what you
did without having to stand on his head and twirl around three times while
muttering "Torvalds" backwards!
> If you don't like the state of kernel documentation, well, then write
> some! Send me a patch!
We're working on making 2.2.14 PPC work on a non-compliant PreP board, so
as I come across stuff, I'll be sure to document what I can and send Linus
a patch, so that hopefully the next guy will understand a bit better.
> P.S. I'll note, though, that adding comments of the form
>
> /*
> * Add one to cobol
> */
> cobol++;
>
> Doesn't necessary make the code easier to read. It's better to optimize
> comments for readiability of those people who *are* willing to spend a
> little bit of time understanding the module, since those are the ones
> which are most likely to give us usable patches. Some duffer which
> expects to pick up the VM code in Linux, and understand it all in 15
> minutes is not someone whom I'll going to trust take patches from
> blindly!
Well, of course. "Adding one to cobol" is meaningless, and adding comments to
stuff like cli() and sti() is just silly, but dropping in comments like
"added to conform to RFC XXXX" are not. For example, I saw a patch that Alan
made to fix some sort of bug with shutdown(), and all it was was "shutdown++;"
and something to the effect of "fixed shutdown() bug". What that meaningful
to Alan? Probably so - but probably not to the person who came after him and
tried to figure out what bug was fixed!
Commercial code typically has comments in it to the effect of "this block of
code fixes bug #13456782", at least, and often has a short description of just
what "bug #13456782" was. Why is there so much pressure to get a driver or
a bug fix out the door that 5 minutes can't be spent to do even the simplest
of comments? Ted, I'm surprised at you - you've been around long enough to
know that meaningful comments are more than helpful. Why the negative comments
about something that your experience tells you can be of use?
-- Ed Carp, N7EKG erc@pobox.com 940/367-2744 cell phone http://www.pobox.com/~erc- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:18 EST