PS/2 and Microport

[Admin]

[Sorry for the tardiness of this stuff, folks.  Apparently a 
 problem existed with something in the mailpath --rcw]

Greetings.

I am looking for information on a variety of Microport topics, and
I'm willing to barter :-)

I've been running a 120 Mb dual-disk 286 machine for a while, all
put together from parts.  One internal modem plus a dumb 8-port
serial card, which has had up to 4 ports simultaneously in use.

At present I'm getting disk errors that I am 99% certain are
software related, but I can neither prove nor disprove that
assertion without source to the silly disk driver.  So...
I'm trying to write a replacement driver, and one for the
#$%^&*() serial ports while I'm at it.  Anyone out there
have source to _any_ interrupt driven driver for the
286 microbug unix?  The ram-disk driver is a good start
but the interrupts are where it gets interresting.

On a related topic, looking at the interrupt assignment
and spl-level chart in the microport "writing a device
driver with dick and jane" manual it occurs to me that
to mask any interrupt on the second controller you have
to use spl7, which in an ideal world would be used by
hardclock and almost noone else.

Guess what kiddies?  The bloody serial interrupts are
also grouped at spl7!  And microbug gives us a patch
point in the kernel to fudge the silly clock.  Putting
a band-aid on a hangnail while gushing blood from the
jugular.

I don't suppose there's any chance of changing the
spl-to-ingerrupt mask mapping without large fractions
of the kernel source, is there?  Moving things around
to correspond to what common sense and sagans of
unix ports show to be the right arrangement might
improve performance and reliability.  Or is it the
document that's wrong?

And now for something completely different: I have
bought (and received!) 2.3 and Merge.  Beware the
2.3 upgrade installation: it will squash almost
anything you've changed in your configuration,
notably (in my case) gettydefs, rc[02], rc.d/* (saves
backups of the last - how nice of them), permission
structure on the "dangerous" stuff...  I don't
remember it all and you will have a different
set of customizations than I so suffice it to say
that the installation document is nowhere near complete
in its list of things that will get squashed.

Is anyone out there running merge in a hostile environment?
It seems to me that running "debug" in the dos mode is the
moral equivalent of running adb on /dev/kmem.  I am really
dissapointed that the system is so vulnerable to damage
from the dos task.  It is simply not acceptable to have
a user task crash the system, period.  Not that Microport
ever lived up to that ideal anyway.  My question is, does
anyone have any suggestions on securing the merge if I
install it?  I suppose it would be sufficient to remove
public execute permission to the merge commands but there
are so many of them that leaving a hole would be too easy
for my taste.

Oh - one more thing - anyone have a line on a 16-but
SCSI host adapter?  As far as I've been able to discover
they're all 8-bitters.  I'm not (yet) willing to give
up that kind of bandwidth just to chunk the WD and
associated driver.

And another thing - anyone got an RLL system going?  I suspect
that all it would take is some well-placed patches in the
driver, since the only visible difference is _supposed_ to
be the number of sectors per cylinder.

Thanks in advance, as they say, for any words of wisdom
(or kilowords of source :-)
	steve
-- 
Steve Nuchia	    | [...] but the machine would probably be allowed no mercy.
uunet!nuchat!steve  | In other words then, if a machine is expected to be
(713) 334 6720	    | infallible, it cannot be intelligent.  - Alan Turing, 1947