On Sat, 2 Apr 2005 08:15, Kuba Ober wrote: > Not really. It just needs some sort of device-class-specific forwarding > protocol. usbfs and libusb already do that, and you should be able to run > any windows driver that way without even touching the kernel.
USB (along with SCSI) is a special case that because of its architecture can participate in such a forwarding arrangement for devices other than the hub or host controller device. Most other device drivers (and when I say device driver I mean the thing that drives the hardware) involve direct use of the input and output instructions of the CPU, and interrupts. Now, you *could* trap the input and output instructions and emulate them via a kernel module, likely one involving entries in /proc to provide an interface for granting access to particular I/O ports and a file that could be used to access each device for which ports were made available. Of course such a mechanism would be much slower than a native driver, and may run into problems with timing issues. Interrupts pose a particular challenge in that ideally the process handling the device should be activated immediately, and the Linux kernel currently provides no interface to say "switch to this task now" - the scheduler code simply does not provide for it (which is a shame, because a directed yield call with an associated call to return the remainder of the donated time slice(*) to the donor would be a "simple" way of radically improving the performance of anything that uses wineserver). So, input an output instructions: possible but likely to be slow, sometimes unacceptably slow. Interrupts are more of a problem due to the inability to do a directed yield. If you seriously want to attempt this, I would suggest your first port of call would be to the kernel list to discuss the possibility of implementing directed yield. * - a directed yield call would allow the current thread to donate the remainder of its current time slice to another thread. The context switch occurs immediately. For maximum value, such a call effectively requires a companion call that allows that other thread to return any of the time slice it does not need to the donor, without necessarily knowing who the donor was.