From: Philipp Rumpf <prumpf@suse.de>
To: frowand@cup.hp.com
Cc: parisc-linux@thepuffingroup.com, Paul Bame <bame@debian.fc.hp.com>
Subject: Re: [parisc-linux] Boot messages from C3000 console
Date: Sat, 23 Oct 1999 01:42:17 +0200 [thread overview]
Message-ID: <19991023014216.C22908@suse.de> (raw)
In-Reply-To: <38109F94.7DA3551A@hp.com>; from Frank Rowand on Fri, Oct 22, 1999 at 10:32:04AM -0700
> one line comment would have made it obvious that the code was calling
> PDC_BLOCK_TLB(). For me, just annoying - for someone who might be missing one
I agree that adding "using PDC_BLOCK_TLB" to the "setup the BTLB" comment might
have been a good idea.
> understand some trivial code. I want to encourage people to make the code
> easily readable so I don't have to waste a lot of time when my help is requested
> to debug or contribute code.
>
> saying that the sequence that I had to read in head.S to figure out the
> cause of the HPMC on the C3000 needed at least a comment to make it readable
I somehow get the impression what you are suggesting is the author of this
code (i.e. me) wrote this code, left for some weeks and you were forced to fix
this bug. What I did was to leave for 38 hours.
Of course it would be nice to have as little code as possible in the tree only
the author understands, and we don't have very much, but I don't think we'll
ever get rid of the last bits of "unreadable" code (in fact, there's enough of
that in the architecture-independent parts to spend a long and busy life
ranting about it). You found some.
Now what you could have done is comment the code, change the code to use
#defines, yell at the author, yell at the author in public, or start a
discussion on how to avoid ever having any unreadable code in the kernel at
all.
You chose (possibly among other possibilities) to have a discussion. I am
not sure which effect you intended it to have, but I am pretty sure the effect
it is going to have, if any, is to waste lots of time that otherwise would
have gone into development, both in the discussion itself and in enforcing
any rules that we "agree upon" (i.e. about which one side gets too tired to
argue about).
My impression is we'll save a lot of time by simply yelling at each other
about bad code as long as the number of developers and users is as low as it
currently is and most likely will be within the next 6 months.
Philipp Rumpf
next prev parent reply other threads:[~1999-10-22 23:41 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-10-21 19:57 [parisc-linux] Boot messages from C3000 console Paul Bame
1999-10-21 21:24 ` Stan Sieler
1999-10-21 22:05 ` Frank Rowand
1999-10-21 22:51 ` Grant Grundler
1999-10-22 0:57 ` Frank Rowand
1999-10-22 2:23 ` Jason Eckhardt
1999-10-22 2:33 ` Alex deVries
1999-10-22 15:15 ` Helge Deller
1999-10-22 17:32 ` Frank Rowand
1999-10-22 23:42 ` Philipp Rumpf [this message]
1999-10-23 3:46 ` Ryan Bradetich
1999-10-22 22:16 ` Philipp Rumpf
1999-10-22 16:06 ` Grant Grundler
1999-10-24 3:44 ` [parisc-linux] Trying to boot on an N-Class Justin Hamilton
1999-10-24 5:22 ` Grant Grundler
1999-10-24 8:43 ` Philipp Rumpf
1999-10-22 22:14 ` [parisc-linux] Boot messages from C3000 console Philipp Rumpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=19991023014216.C22908@suse.de \
--to=prumpf@suse.de \
--cc=bame@debian.fc.hp.com \
--cc=frowand@cup.hp.com \
--cc=parisc-linux@thepuffingroup.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.