Date: Sun, 16 Nov 1997 07:23:41 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jamil@trojanhorse.ml.org (Jamil J. Weatherbee) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: AIOX Analog driver statistical analysis Message-ID: <199711160723.AAA08576@usr06.primenet.com> In-Reply-To: <Pine.BSF.3.96.971115213248.273B-100000@trojanhorse.ml.org> from "Jamil J. Weatherbee" at Nov 15, 97 09:51:39 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711160723.AAA08576>