domo@uunet.uu.net (Dominic Dunlop) (12/10/88)
[[ This is part of a discussion on comp.unix.xenix. --wnl ]] In article <1778@qiclab.UUCP> neighorn@qiclab.UUCP (Steve Neighorn) writes: >In article <2139@ficc.uu.net> peter@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@sphinx.co.uk domo@riddle.uucp