> I recall some discussion in which Steve P. was involved,
> about a conflict between the HPUX  X server and the UVM
> subsystem "officially" implemented in 1.4.x:
> Dump core  of the X server / system lock when quiting X.

The HP-UX X server has dumped core on exit in NetBSD since I first
started using it long before UVM came along.  With the advent of UVM,
I started getting kernel panics at exit instead.  These are both
because some unimplemented optional graphics driver features cause
the server to rather bogusly attempt to unmap an unaligned internally
generated address on exit.  The grf driver passes this address into
uvm_unmap().  It appears that some of the changes that have been made
in UVM since I ran into this have made the panic much less likely
although I maintain that the problem is still there - grfunmap() will
pass an address into uvm_unmap() without any validity checking.

I implemented a local fix for this that verifies that an address passed
into grfunmap() was previously mapped by grfmap() before doing anything
with it.  I'm not thrilled with this solution at the moment because it
has some ugly complications in the presence of fork() that are currently
not handled and would require some sort of MD hook into fork() and exit()
processing (ick).  The X server won't encounter these complications but
still...  It might be better to do what munmap() does and page align the
address before passing it to uvm_unmap() but the framebuffer size isn't
really the right thing to use in this case either.

If you just want to get running on 1.4.x and don't mind egregious hacks
you can alter grfunmap() to reject anything other than 0x1000000 since
that's the address grfmap() always returns for the HP X server's GCMAP
request.  Slightly less bogus would be to reject anything not page
aligned.  The X server won't care if you fail this particular request -
it's on its way out anyway.

> I vaguely remember there is even a PR about this. If my memory
> serves me the discussion in the PR was in terms of file system
> pollution when implementing HPUX emulation.

I suspect you're thinking of a separate issue here (although it does
involve the HP-UX X server again).  The server creates its socket in
/usr/spool/sockets/X11.  The emulation code doesn't translate the
path into the emulation tree for unix domain socket creation so one
is forced to have this "alien" directory in the main file system.
There are good arguments both for and against changing this behavior
(but consistency, which is currently not present, would be nice).
Personally, I just create a symlink from /usr/spool to /var/spool
and stop worrying about it.

-Steve