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.