From owner-freebsd-hackers Sat Nov 15 23:23:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA24488 for hackers-outgoing; Sat, 15 Nov 1997 23:23:53 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA24483 for ; Sat, 15 Nov 1997 23:23:50 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id AAA22280; Sun, 16 Nov 1997 00:23:49 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp03.primenet.com, id smtpd022230; Sun Nov 16 00:23:43 1997 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id AAA08576; Sun, 16 Nov 1997 00:23:41 -0700 (MST) From: Terry Lambert Message-Id: <199711160723.AAA08576@usr06.primenet.com> Subject: Re: AIOX Analog driver statistical analysis To: jamil@trojanhorse.ml.org (Jamil J. Weatherbee) Date: Sun, 16 Nov 1997 07:23:41 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Jamil J. Weatherbee" at Nov 15, 97 09:51:39 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Keep in mind that select returns as soon as a single entry is available in > any channels fifo. I am thinking about adding an ioctl() that would allow > the user to specify a select() trigger point, say they could tell the > driver to not do a selwakeup() unless the fifo is more than half full. Of > course using blocking I/O with huge buffers solves this a bit (and I will > be testing that also), but that precludes any kind of virtual multitasking > in a single code thread for multiple channels. If it blocking I/O solves the problem, and the only thing you are doing is I/O processing (ie: you don't plan to use select to poll the device and do other things) you might consider "packetizing" data from the device. You would do this by writing a byte indicating the channel in front of each "packet" of data on the channel. (ie: if the first character read is "0x05", then the remaining data from that read is from channel 5, etc.). Effectively, you would have a device MUX. This would let you use a single read to read all channels, and block in user space pending data on any active channel. Alternately, you could "select" on the devices in user space using the select system call, with a timeout, to provide a virtual task manager for other devices if you needed that. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.