Wine device drivers proposal

[Andreas Mohr]

Hi,

On Mon, Apr 04, 2005 at 08:58:32AM +1000, Troy Rollo wrote:
> 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).
AFAIR (some recent discussion?) there were good reasons for not implementing
that, since it isn't all that helpful. But I'm not sure...

> 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.
Nope, that should probably be the Con Kolivas list, since they do a LOT more
about scheduling things.

An interesting experiment could be using a recent Con Kolivas kernel
(2.6.11-ck3) and installing schedtoold and let wineserver run in isochronous
scheduling (SCHED_ISO). Then try some "nice" games to see what happens...

Andreas Mohr