Subject: Re: those dumb questions
To: Andrew Gallatin <gallatin@isds.Duke.EDU>
From: Ted Lemon <mellon@vix.com>
List: port-pmax
Date: 03/16/1995 17:19:17
> 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 ;-)

Shit.   I run with a umask of 027, and apparently the system took that
when installing the tree.   I thought I'd dealt with that, but
apparently not.   Sigh.   The embarrassing thing is that I've been
scratching my head trying to figure out why dates weren't printing
right for about two months now... :')

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

Are you volunteering to write a FAQ?   I'd really appreciate it if you
have the time!

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

I haven't run into those problems.   I don't use yp, so that's no
surprise, but I do get fscks.  Sigh.   I may not be running the
distributed rc - because of some kernel problems I've been having, I
haven't been able to boot an install from a clean distribution yet.
Sigh.

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

Welcome to the wonderful world of building kernels from -current.
This is probably not a pmax-specific problem.

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

Nope.   The pty code is all in the machine-independent part of the
kernel.   You may just be losing because tcsh gets you out of line
mode.   This definitely bears investigation, though - I'm *not* having
this problem and I'm running the same version of tcsh.   Actually, if
you want, you can try my tcsh binary and see if it makes a
difference...

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

This shouldn't be true.   Let me know if experimentation proves that
it is...

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

Your only real reference is the code.   Ralph Campbell (or maybe it
was Rick Macklem) had an X server running on the 3100 at one point,
but I have no idea how that was built.   The Xws server definitely
doesn't build - some headers are missing.   You may be able to get the
Xdec server to build fairly easily, though.   That'll probably only
support 3100 and cfb machines, though.

> Has anybody yet tried to get Ultrix Xws or
> Xdec to run under Ultrix compat mode

I'm almost positive this won't work, but by all means attempt the
experiment.   I'm pretty sure the device drivers we're running don't
support the new-style interface, but I haven't researched this
closely, so I could be wrong.

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

I don't think anybody's got it going at this point.  Please feel free
to learn what you can.  Extra points if you actually get something
working.  Bear in mind that the existing frame buffer code is widely
hailed as an example of true lameness, so if you see something that's
begging for a rewrite, don't be bashful.  Please do bounce your ideas
off me before striking out on a major rewrite, but don't be afraid of
offending anybody - a lot of what's in the pmax tree right now was
implemented in the spirit of ``just get the damned thing working'',
not ``this is what it should look like when it's done.''

			       _MelloN_