VPIX (Re: DOS under Xenix)

[Dominic Dunlop]

[Note Followup-To: above]
[Apologies if this is a duplicate posting.]

In article <1778 at qiclab.UUCP> neighorn at qiclab.UUCP (Steve Neighorn) writes:
>In article <2139 at ficc.uu.net> peter at ficc.uu.net (Peter da Silva) writes:
>>Has anyone managed to run intel's MSNET OpenNET software and network
>>card under VPIX? ISC doesn't think it's possible, but I've heard rumors
>>it's been done.
>
>It is possible to run an Intel etherlink card and OpenNET software under
>a MSDOS window on a Sun 386i. The DOS emulation on the 386i is based on
>VP/ix. This setup has been used as a bridge between TCP/IP and OpenNET,
>a deed formerly thought beyond the realm of possibility.
>
>Within the guidelines set by Sun, all the PC cards tried in the 386i
>have worked, once they were configured correctly, and the hardware
>information was placed in the correct files. This list of cards include
>ethernet cards and VGA cards.

Yes.  Speaking straight off the top of my head (a rather barren area these
days), but with some clues from a Sun person I talked to at the recent
London V.4 Developer's Conference, I'd say that the 386i is liable to run
far more PC option cards straight out of the box than is a 386-based AT
clone.  The reason for this is that the AT bus in the 386i is private: its
only reason for existence is to service I/O requests originated by
programs running in DOS windows under UNIX.  All that the operating system
has to do on trapping any unrecognised I/O request (that is, one not
addressing a standard device like the floppy or hard disk) which occurs
when the processor is in virtual 8086 mode is to map it onto the private
AT bus, where, presumably, there is hardware which will recognise it.
I'd guess -- although I don't know for certain -- that the same applies to
references to addresses that look like shared memory belonging to devices.
Similarly, any interrupt or DMA request originating on the AT bus has got
to be something to do with a virtual 8086 process.

In contrast, in an AT clone, the AT bus is shared by UNIX running in 80386
native mode, and by DOS jobs running in virtual 8086 mode.  All the
devices have the potential of being shared, too -- even if you've added
them exclusively for use by DOS.  Consequently, DOS I/O cannot be allowed
straight onto the bus, in case it interferes with UNIX' use of the same
devices.  Instead, DOS I/O requests must be comprehensively vetted by UNIX,
and possibly mangled a good deal, before being permitted to access the bus.
When last I looked, this entailed writing a UNIX device driver for each
type of option card, supporting (at least) ioctl() calls which simulated
the action of 8086 IN and OUT instructions.  (If you wanted UNIX as well as
DOS access, you had to add read(), write(), open(), close, and so on, too.)
This was quite enough to ensure that making an arbitrary AT-bus card work
from VP/ix is far from easy.

Of course, both in the 386i and in a PC running UNIX, virtual 8086s have to
be fooled into thinking that they can directly diddle with device registers
controlling the standard peripherals such as soft and hard disk, keyboard,
interrupt and DMA controllers, printer port, and so on.  Consequently,
VP/ix in either environment is supplied with enough software driver smoke
and mirrors to allow DOS to share these devices with UNIX.  After that, the
386i needs only one more driver -- the generic AT-bus driver, which is
supplied as standard by Sun -- whereas UNIX running on a PC generally needs
a special driver for each new device.

Comments, anybody?  Does my information reflect the current releases of
VP/ix, or have things got better?
-- 
Dominic Dunlop
domo at sphinx.co.uk  domo at riddle.uucp