root@qetzal.UUCP (Admin) (02/05/88)
[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