From owner-freebsd-hackers Sat Nov 1 18:57:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA23639 for hackers-outgoing; Sat, 1 Nov 1997 18:57:01 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (ppp13.portal.net.au [202.12.71.113]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA23634 for ; Sat, 1 Nov 1997 18:56:53 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id NAA00521; Sun, 2 Nov 1997 13:22:24 +1030 (CST) Message-Id: <199711020252.NAA00521@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Jamil J. Weatherbee" cc: hackers@freebsd.org, dufault@hda.com Subject: Re: Strategy Routines In-reply-to: Your message of "Sat, 01 Nov 1997 12:24:20 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 02 Nov 1997 13:22:22 +1030 From: Mike Smith Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > period. Now I know that if the drivers routine can be interrupt driven > the this is all solved, but if (as in digital_out_strategy() in labpc.c) > someone passes a 1/2 megabyte buffer, youv'e got a problem as your going > to be out of business for at least .5 seconds. So how can the equivalent > of reschedule() under the linux kernel be done in here. You could then > limit yourself (in the drivers) to say 1024 bytes written then a > reschedule() to maintain the interactivity. This is a fault in the driver design. Drivers should not hog the cpu, obviously. Try calling tsleep() out of the driver with a very short timeout. mike