As I mentioned earlier, I've just installed the binary release of
NetBSD pmax on a 3100, bootstrapped using an Ultrix version of
NetBSD disklabel & Jonathan's 2-14 miniroot.

I've got a few comments/questions.  Some of them may not be pmax
specific, so I apologize in advance.  

I also don't want anybody to think that I'm just whining because
NetBSD/pmax is not a polished, production ready OS just yet.  On the
contrary, its come one heck of a long way since I first started
playing with it last summer & I'm *VERY IMPRESSED*. With that said,
here's my questions/comments:

o On the binary dist

Lots of gcc things are not world-executable, and the /usr/lib/gcc-lib
hierarchy isn't read/executable.  I noticed this when attempting to
compile a kernel as myself ;-)

Also, the /usr/share/zoneinfo files are not world-readable - this
drove me nuts for a little while, 'till I thought to check the
permissions..


With a kernel or two sitting in it, the root partition needs over 16M
- mine's at 19M now w/2 kernels - perhaps it would be good to warn
people of this & tell them to use a 32M root.

When going multi-user via exiting the single-user shell, disk-checks
are skipped.  It looks like /etc/rc looks for $1 to be autobootx & it
gets only x.  Also, ypbind is only started if the ypserv files are
around, which seems a little strange.


o kernels

I managed to rebuild my kernel last night after supping the kernel
sources.  I had a small problem in that a reference to nclist on line
613 of machdep.c came up as undefined.  Having no clue what do do, I
copied the following definition of nclist out of param.c (omitting the
ifdefs): 
#ifdef REAL_CLISTS
int     nclist = 60 + 12 * MAXUSERS;
#endif

Apparently, REAL_CLISTS wasn't defined - what kernel option gets it
defined?  Or should the reference in machdep.c :
valloc(cfree, struct cblock, nclist);
be protected by ifdefs? 

Also, when re-building my kernel using the 2-14 generic kernel the
system wedged.  Many procs (my shell, inetd, rlogind, etc) were in
stuck in D waits.  This happened twice in a row when the make of the
kernel failed.  I was able to halt the system via an existing console
login.  Both the kernel sources & my home directory (I was building as
me) were nfs-mounted, so I'm thinking something might have broken in
the nfs-code.

o general questions

I built my favorite shell (tcsh 6.05) and its acting just a little
strange - when logged in from home via slip, its painfully s-l-o-w to
type on, but it seems just fine over a local connection.  I've never
seen it behave like this (ie, it runs just fine via slip on the same
machine running Ultrix, or any machine running any other OS).  Are
there any tempory hacks to the tty handling code that could be causing
this behavior?

I seem to recall one must have DIAGNOSTIC or DEBUG defined to get
the COMPAT_ULTRIX code to work.  Rebuilding w/o the above defened
broke ultrix compatibility .. everything exits with 'bad system call.'
I'm rebuilding right now to test my theory.

Where's the best place to read-up on attacking a frame buffer to make
X run?  What's the easiest one to attack?  It looks like there's
already stuff in pmax/dev for the frame-buffers - is it just a matter
of convincing X to build?  Has anybody yet tried to get Ultrix Xws or
Xdec to run under Ultrix compat mode ... that's basically what the
Sparc port does, right?  I'm really interested in getting X working,
but I don't want to re-invent the wheel if anybody else has worked on
it. 


o This is looking really WONDERFUL!

Drew