Cool...., sounds like you've been doing some really hard thinking.......
Now if there were more of us who knew how to code those things...... (My
specialty is crash-testing, seeing as I seem to be able to crash
anything--LINUX & FreeBSD included....;^)!!)
Drew Northup, N1XIM
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
> Of Colin Davidson
> Sent: Monday, November 06, 2000 4:58 PM
> To: Plex86
> Subject: Peripheral considerations
>
>
> Hi Everyone,
>
> There are some general issues and trade-offs around peripheral
> handling that
> I thought worth thinking about in general and bearing in mind while we
> discuss particular peripheral situations.
>
> There are at least four approaches to supporting peripherals in
> Guest OSes:
>
> 1) Segragate the machine. Have the Guest OS use one set of
> hardware and the
> Host OS another. This is very little work, most of which is required
> regardless of the approach actually taken, but requires extra
> hardware (LAN
> card, display adapter, mouse, keyboard, disk controller and hard
> disk ... At
> some point, you ask yourself why you don't just use 2 machines. In some
> circumstances, though, it will give maximum performance for minimum effort
> and can be really worthwhile if you need either (graphics comes to mind
> here).
>
> 2) Emulate a known piece of hardware - Ne2000, 3dfx voodoo3, etc, etc. Use
> the standard Guest drivers but punt their implementation to a host device.
> This allows the support to be written once, but kept up-to-date with the
> latest driver from the hardware supplier - for as long as that supplier
> supports the device in question. It relies on the hardware spec.
> being well
> enough known to emulate and assumes that the hardware/driver interface is
> simpler than the OS/driver interface. As it is at a lower level than the
> OS/driver interface, it will almost inevitably be less efficient than a
> higher-level emulation.
>
> 3) Emulate an virtual piece of hardware, designed to be easy and efficient
> to emulate. This hardware does not have to have any real existance. The
> Guest driver captures the OS requests and passes them over to a
> corresponding handler on the Host. This will be about as efficient as
> emulation can be, but may need frequent updates in rapidly changing areas
> (DirectX, e.g.). It assumes access to Guest driver writing capabilities
> (Windows DDKs, e.g.) and suffers from a potential problem of only being
> partially open-source, as the driver may have to live "in" a proprietory
> environment. Nonetheless, it may be well worth pursuing in cases where the
> driver needs to be efficient but dual hardware is prohibitive.
>
> 4) Use to same hardware in both OSes. This is really only possible for
> stateless, synchronous peripherals, such as keyboards and mice, perhaps
> (also potentially devices such as printers, which can report a "busy"
> condition while being used by the other OS. Stateful peripherals, such as
> display adapters, and asynchronous peripherals, such as LAN cards and
> Modems, are a poor choice for hardware sharing. In most cases,
> this is a BAD
> IDEA. Even where hardware can be share, some mechanism is required to
> enforce sharing, so that only one OS at a time will actually access the
> hardware.
>
>
>
> Note that in many cases, these option will not be exclusive and the actual
> best solution will depend on the situation at hand - what the user can
> afford, what applications are running, personal ideology and a
> host of other
> factors. Where possible the implementation of a solution should
> not prohibit
> the implementation of an alternative. This really is a case of
> the more the
> merrier, so long as we get *something* working in a reasonable timeframe.
>
> Cheers, Colin
>
>
