From: Philipp Rumpf <prumpf@suse.de>
To: frowand@cup.hp.com
Cc: Paul Bame <bame@debian.fc.hp.com>, parisc-linux@thepuffingroup.com
Subject: Re: [parisc-linux] Boot messages from C3000 console
Date: Sat, 23 Oct 1999 00:14:43 +0200 [thread overview]
Message-ID: <19991023001443.A22908@suse.de> (raw)
In-Reply-To: <380FB68D.A8F28E62@hp.com>; from Frank Rowand on Thu, Oct 21, 1999 at 05:57:49PM -0700
> I'm cutting this from another discussion, don't feel like re-typing it.
> The file we are talking about (giving line number references) is head.S.
> We calculated the the offending offset was at label "blargh" plus a bit.
>
> The following discussion talks about how we get to the code section
> where the HPMC occurs. Earlier, we talked about hard-coding magic
> addresses, which are machine specific (that's in the macro "debug",
> which is what actually caused the HPMC -- line 162).
The debug macro should indeed have been empty (and is, now). Sorry for that.
> Then I get a little incensed at the coding style here.... (editing out other
> people's responses to my tirade)
>
>
> > This is a **bogus** way to write code. Comments should be required!!!!!!
> Is there any way to encourage that?
there is a comment on top of the section of code in question
/* setup the BTLB. XXX: This assumes a unified BTLB */"
which I agree isn't as verbose as it could be but it seems not to hard to me
to get to "we do a PDC_BLOCK_TLB call now" from "setup the BTLB".
> > But I'm *extremely* serious about that. This code is unmaintainable in it's
> current form. It's going to be miserable adding 2.0 support to something
> like that.
indeed it is, which is one of the reasons I proposed to wrap the virtually-mapped
kernel in a physically-mapped som binary which could do these pdc calls in C (and
would remove the need for most of head.S)
> > it's important to anyone who would like to pick up head.S and be able to
> read it. To decode the procedure call I had to know where to find
> documentation for page zero, know what PDCE_PROC is, figure out what PDC
> procedure was being called.
> > For me, it was about 45 seconds instead of the two seconds it would take to
> read a comment.
> > For someone who doesn't have my background, it could be hours.
I cannot exactly remember whether this was based on gcc-generated code, but I
am pretty sure it was, which might explain why it doesn't use macros (of course,
it would have been a good idea to include the C code as comment in this case).
Philipp Rumpf
prev parent reply other threads:[~1999-10-22 22:13 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
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 ` Philipp Rumpf [this message]
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=19991023001443.A22908@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox