Wine device drivers proposal
andi at rhlx01.fht-esslingen.de
Mon Apr 4 02:53:17 CDT 2005
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
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...
More information about the wine-devel