Wine device drivers proposal

[Troy Rollo]

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.