From owner-freebsd-hackers Mon Apr 8 03:15:14 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA17428 for hackers-outgoing; Mon, 8 Apr 1996 03:15:14 -0700 (PDT) Received: from blah.a.isar.de (root@blah.a.isar.de [194.45.233.130]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id DAA17416 for ; Mon, 8 Apr 1996 03:15:04 -0700 (PDT) Received: (from roell@localhost) by blah.a.isar.de (8.6.12/8.6.9) id LAA00308; Mon, 8 Apr 1996 11:47:34 +0200 Date: Mon, 8 Apr 1996 11:47:34 +0200 From: Thomas Roell Message-Id: <199604080947.LAA00308@blah.a.isar.de> To: Michael Smith Cc: terry@lambert.org (Terry Lambert), roell@blah.a.isar.de, hackers@FreeBSD.ORG, jkh@time.cdrom.com, roell@xinside.com Subject: Re: The F_SETOWN problem.. In-Reply-To: <199604080229.LAA08202@genesis.atrad.adelaide.edu.au> References: <199604072000.NAA00425@phaeton.artisoft.com> <199604080229.LAA08202@genesis.atrad.adelaide.edu.au> Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In your message of 8 April 1996 you write: > > The fix here is to virtualize all mouse I/O in the kernel instead of > > presenting seperate abstractions that the X server has to deal with. > > This would be a wonderful idea. Except that convincing a vendor like > SunSoft or SCO that your new spiffo mouse protocol was Just The Thing > might not be so easy. 8( It's even worse. What if you want to add support for a new graphics tablet ? Relink the kernel, and add a kernel driver ? This is kind of too much for the avare end user. I could do this with SVR4, which allows to push STREAMS modules ontop of let's say a serial device. But still it's to complex to be used realitically. > > b) You are taking too long in your atomaton before getting back > > to the state where the buffered events can be processed, and > > you need to fix the automaton. > > Not being anything of an Xpert, I can only suggest that the automaton is > as it is for the sake of efficiency. Breaking it down and persistently > selecting may well significantly degrade its performance. Right. You have two ways with the current scheduling. Either increase temporal performance by decreasing interactivty, or increasing interactivity by decreasin overally performance. The only way to get out of this deadlock is either to seperate the device-io from the client-io, or use a dynamic schedluing, which then again solves only part of the problem. - Thomas -- Denver Office THOMAS ROELL /\ Das Reh springt hoch, +1(303)298-7478 X INSIDE INC / \/\ das Reh springt weit, 1801 Broadway, Suite 1710 / \ \/\ was soll es tun, Denver, CO 80202 roell@xinside.com / Oelch! \ \ es hat ja Zeit.