Subject: Re: progress report & thanks
To: Arne H. Juul <firstname.lastname@example.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 08/28/1995 13:27:45
My thanks to Arne for the compliments and for taking the time to build
a new kernel. Please noet that I'm attending SIGCOMM for the rest of
the week and won't be likely to respond to e-mail.
> There has been changes in the pmax
>sources since then (I used somewhat oldish sources), but these are the
>things I remember I had to do:
> /sys/arch/pmax/tc/tc.c #includes <pmax/pmax/trap.h>, which does
>not exist (at least not in my sources). I made one and put some extern
>declarations into it which tc.c complained about, and that worked ok.
I just fixed that. Not checking in trap.h was an oversight on my part,
when checking in a snapshot of my "development" source tree.
> I also had the same if_tt, random.c, and min.c problems that Simon Burge
>has reported. I've seen your PR on this, Jonathan - has this been
The if_tt is a hangover from my own source tree; I haven't received
all the paperwork and boilerplate I need to release it to -current.
I've commented it out of the config file until then.
To my knowledge, the random.c Makefile problem in libkern hasn't been
About min.c: I think I object, on principle, to providing non-inline
definitions for functions like min(): declarations for them
(prototyped, if possible) should be in scope when they're used; and if
the prototype _were_ in scope, so would the 'static inline'
definition. AFAIK, despite the pmax port seemingly never having built
a non-inline min() et.a., this problem only occurs with
scsi/scsi_ioct.c. I'd rather see that file have an #include line that
gets a declaration (i.e., #include <sys/systm.h>), and an inline
definition, than hack around what I think is an #include bug.
Others (perhaps including Core) may disagree.
> While on the subject of PR's, I have a PR (1048) for modf in the
>C library for pmax (or rather mips) which seems to have been somewhat
>forgotten - could one of you (Ted or Jonathan) check it out? I think it
>should be OK.
I've never seen _any_ PR's except the ones I send. I don't seem to
find time to keep up with them. Perhaps I should investigate getting
myself set up to see (and possibly deal with) PRs for the pmax port.
(Yet more e-mail to keep up with...)
Arne, if you send me the proposed changes, I can at least peruse
them, with a view to committing them. Officially I beleive it's
under Ted's purview, but he doesn't have time right now.
> Also, brk.S and sbrk.S in /usr/src/lib/libc/arch/mips/sys
>hasn't been fixed yet
What ? The ASMSTR() buglet? That's two months old, isn't it?!?
That makes me wonder if anyone's actually *doing* anything about