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
