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
>resolved yet?

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
fixed.

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
pmax send-prs.

--Jonathan