G.LEB@MIT-EECS@MIT-AI@sri-unix (06/11/82)
From: lawrence e bakst <G.LEB@MIT-EECS@MIT-AI> Date: 31 May 1982 0230-EDT Date: 31 May 1982 02:20:11-EDT From: leb at mit-vax To: G.LEB@mit-eecs, leb@mit-vax Subject: [Dan Franklin <dan@BBN-UNIX>: Re: kernel: clist code question] it was done by someone at bell, if cc < 0 then the first and last pointers point to contiguous buffer (usually a disc buffer). the packet driver that came with v7 uses it, as does some software that runs at bell. newer versions of prim.c have more support for it. on the subject of unix buffering... has anyone thought that it's time to rethink it. perhaps there should be one scheme which supports terminals, networks, and discs. i've made a start at the company that i work for. my new primatives are basicly linked lists of arbitrary size buffers. the arbitrary size buffers allow me to support both input and output dma. routines are available which allow network devices to run efficeently, yet mesh in with all the standard primatives. i support many more functions than the standard prim.c. it now supports both ttys (the std v7 tty.c took about 20 mins to modify) as well as ethernet devices running on a custom 68000 system. it doesn't support discs yet, but i think it could. has anyone done any similar work? maybe thought about doing something similar? network devices have to stop ripping of buffers from the disc pool. what do you do for packets > 512 bytes? go to 1k file systems? ps note on raw speed of my routines vs prim.c using the 2 basic primatives. on a pdp-11 i benchmarked the standard prim.c doing getc/putc at about 4166 chars per sec . my routines benchmark at about 3448 cps. larry -------