Date: Thu, 13 Nov 1997 11:49:36 -0800 (PST) From: "Jamil J. Weatherbee" <jamil@trojanhorse.ml.org> To: John Kelly <mouth@ibm.net> Cc: Bruce Evans <bde@zeta.org.au>, hackers@FreeBSD.ORG Subject: Re: Status of 650 UART support Message-ID: <Pine.BSF.3.96.971113114009.551A-100000@trojanhorse.ml.org> In-Reply-To: <346d4ceb.8671504@smtp-gw01.ny.us.ibm.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Speaking of elastic buffers, this is the kind of thing that I really need in my data acquisition stuff because much like sio once those things are open data is basically spewed in. Perhaps somebody would care to do a general "elastic buffer" implementation where the driver could set a threshold saying that for instance "there is no way I could fill more than nn bytes in a second" and then every second the elastic buffer module could reevaluate the drivers need for buffer based on how much it had actually filled and provide additional margin until the next second. Of course this would also need to be bounded someway. A better solution of course would be a realtime extension where you could somehow force the incoming data off into userspace (and you wonder why networking is done in the kernel??). ** Note: very general idea!! Someone help me out here ** The big difference on these kind of devices is that the user _doesn't_ ask for data, it just arrives. So all the fancy buffering in the world isn't worth shit if it is not _immediately_ available in the interrupt routine. Hell that might be the solution -- you should be able to have 2 fifos, when A fills up switch to B and force the A to be exchanged for C by the kernel. Then maybye A would be force off to a unix domain socket somewhere. I am not really sure what happens to unix sockets that get spewed to. On Thu, 13 Nov 1997, John Kelly wrote: > On Thu, 13 Nov 1997 20:35:53 +1100, Bruce Evans <bde@zeta.org.au> > wrote: > > >>Why can't we handle large bursts of input? > > > >Buffer sizes are finite. > > Can't we use malloc to create elastic buffers on the fly? Is that a > no-no in the kernel? > > >Multiply some of these numbers by 4 for 64-bit fifos and you have > >seriously high (normal worst case) latencies. (My definition of ``high'' > >is anything that would stop an 8250 from working at 115200 bps - 87 > >usec :-). I will reduce this when faster speeds become common.) > > Why not start from scratch and develop siov2.c which uses elastic > buffers, 650 polled vs. interrupt mode switching, yada, yada, yada. > Sio.c could still be the default while siov2.c could be selected on a > port by port basis with a kernel config flag. > > Now if someone foolhardy enough to undertake such a project would step > forward (don't look in my direction, I know better). ;-) > > John > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.971113114009.551A-100000>