the <mips/endian.h> problem has been converted to use u_int32_t and
u_int16_t, but this probably needs to be backed out for now, like
it has been for i386:

 > jtc
 > Wed May  8 16:00:40 EDT 1996
 > Update of /a/cvsroot/src/sys/arch/i386/include
 > In directory pain.lcs.mit.edu:/a/tmp/cvs-serv20523
 > 
 > Modified Files:
 >         endian.h 
 > Log Message:
 > Revert last change.
 > Changing types from unsigned {long,short} to u_int{32,16}_t causes problems
 > in a lot of userlevel code because those types aren't defined when machine/
 > endian.h is included.  And IMO including sys/types.h in machine/endian.h
 > is clearly wrong.
 > 
 > XPG4.2 defines new types in_addr_t and in_port_t for the {h,n}to{n,h}{l,s}
 > functions.  But we don't have time to figure out the implementation issues
 > given the current release schedule.

I got problems in the C library, when compiling strtod.c and
infinity.c at least.

Another question: <mips/endian.h> actually defines the byte
order and so on.  But mips is dual-endian, so looking forward
to the SGI or other big-endian mips port of NetBSD, shouldn't
the little-endian version be in pmax/include/endian and
pice/include/endian?  Of course, this is easy enough to change
later.  Actually, it would be nice if there were generic
32-bits bigendian and little-endian versions of this file.
The sparc and m68k versions are now almost (but not quite)
identical.

  -  Arne H. J.