Executive Summary:

I honestly don't know what's broken in half of Gordon's points, and
the other half are outside my control, or beyond my time constraints
to fix...

GM> [NetBSD/pmax is still not production quality, in any event, but
GM> I'm hoping it will be soon.]

JS> What needs to be fixed to make NetBSD/pmax production quality?



Gord Matzigkeit replies:

GM>1) PMAG-BA accelerated 2-D graphics card driver support.  I don't know
GM>where to begin with this.  20 of our 45 5000/120's use the PMAG-BA
GM>card, and up- or downgrading is not a possibility.

I don't understand this request at all.  Are you sure you mean
the PMAG-BA and not something else?

Ted Lemon may correct me here, but: the PMAG-BA is the so-called SFB.
There's an SFB driver, and if you put "options MELLON" in the kernel
config file, then it should just work.  It does break the CFB support,
though.  I have a putative fix for the RAMDAC driver, to make a single
kernel work on either an SFB or a CFB.  There's no real use made of
the accelerator support, since I don't know how it's used!

The person I sent the diff to test never replied.  If you can
test this, or send me an SFB so I can test it, then the fix
will get into the kernel tree.


GM>2) X11R6 server that works on PMAG-B as well as the other devices.  I
GM>heard something about IOCTL support that would do the trick, but
GM>nothing seems to have come of it.

If you want it, write it :).  It's a Simple Matter Of Programming:
ripping the old-style, pre-Xws Ultrix code out of X11R5 (under the ddx
subdir of the X server source) and dropping that code into X11R6.
As I've said before, I do not have time to do this myself, and I doubt
I ever will.  Please take that as an invitation.

GM>3) Shared libraries.  If I had an ld that would produce shared objects
GM>without SEGVing, then I'd just compile the GNU C library, and use
GM>their ELF ld.so.  But, I don't know if the gcc that comes with
GM>netbsd/pmax even does PIC.  Somebody mentioned that they have a PIC
GM>toolchain, and were writing an ld.so, but nothing seems to have come
GM>of it.

Per Fogelstrom (pefo@enea.se) was working on this.  I haven't done
anything on it, as Per was working on it.  If the GNU libc already has
an ELF ld.so that works on a mips cpu, then I think we should just use
it.

Per has a GCC and a binutils that builds ELF PIC mips objects.  Why
don't you see if you can get that, and try building a shared GNU libc
with it?

In fact, Per, can you send it to me and I'll put the binaries in
the next snapshot I make?


GM>4) An implementation of sigstack (a missing function) for the C
GM>library.  I reported this problem this week.

>From the NetBSD manpage for sigstack():

>SIGSTACK(2)               NetBSD Programmer's Manual               SIGSTACK(2)
>
>NAME
>     sigstack - set and/or get signal stack context
>
>DESCRIPTION
>     The sigstack() function has been deprecated in favor of the interface de-
>     scribed in sigaltstack(2).
>
>SEE ALSO
>     sigaltstack(2)

As far as I can tell, no NetBSD port provides sigstack().  At least, I
can't find one anywhere in /usr/src/libc.  It's present in kernels
only for binary compatibility.  Perhaps you should write a library
version of sigstack() for your application, using sigaltstack?

If you think NetBSD should have such a library routine, then please
send a PR about libc.  I don't know how the relevant people (probably
JT Conklin, amongst others) would respond to such a request.  I can
see arguments in favour of stamping out old, pre-posix 4bsd interfaces
in favour of POSIX interfaces.

GM>5) A GDB that can actually trace program execution.  The one in the
GM>snapshot doesn't know what source line it is at, even for hello-world
GM>programs compiled with -g.  I reported this before Christmas, but
GM>nothing seems to have come of it.

Uh...  it seems to for me ?!?.  That I will look into.

GM>6) Robust Ultrix installation instructions.  This isn't a priority for
GM>me right now, but I may end up working on this (simply because I don't
GM>have the right skills to handle my other nits).

You mean robust instructions for taking a machine running Ultrix and
getting NetBSD/pmax on it?  I wrote the installation guide off the
NetBSD/pmax web page as my best shot at installation instructions.  If
they're not good enough, or not robust enough, please do find your
own notes,  add them to the material in the Web page, and
I'll add that in.

I haven't tried following Arne's instructions.  Maybe that's what
you're referring to.  They are *significantly* different from the web
page.  I've seen messages here from a couple  of recent installers of
NetBSD/pmax who followed the web page.  They seem to have had
reasonable success.

What are the flaws with either set of instructions (Arne's or mine),
what are they *missing*,  and where could they be improved?

If someone has suggestions, I'd be glad to add material.  But I can't
fix something if I don't know it's broken.  And I've been building and
installing miniroots and OS distributions for so long that I honestly
don't *know* what might be useful to have in the Web instructions: I
just type it, literally without thinking about it.


GM>7) Getting the GNU people to config.guess our canonical name as
GM>mips-dec-netbsd1.1A rather than pmax-unknown-netbsd1.1A.  It's
GM>irritating to have to explicitly give host parameters to the configure
GM>command.

That's not under the control of the NetBSD team, per se.  Please send
bug reports to the relevant GNU mailing lists. Or maybe even a bug
report to *all* GNU mailing list.  (I have, for some GNU packages, and
it doesn't seem to have gotten anywhere yet.  We have to wait for the
release cycle to catch up.)

Emacs, in particular, will require some non-trivial surgery to configure
on a "mips-dec-netbsd" system...


GM>Thanks for asking, anyway...

You're welcome.  However, I simply cannot single-handedly support and
enhance all of NetBSD/pmax on my own.  I can completely understand
that the user community would like to see more support and more
functionality for NetBSD/pmax.  So would I.  However, that has to come
*from* the user community.  I simply do not have time to do more than
I'm doing already.

--Jonathan