Re: pipes & ptys

[Juergen Lock <nox@jelal.north.de>]

Howard Chu writes:
>    now how fix this (i mean _really_ fix this. so that a 1k read ends up
>   as one 1k device read whenever possible, without additional moving data
>   around) and stay compatible with existing devices?  here is an idea...
>   
>   1. add 2 optional functions to DEVDRV struct, for now i call them bread
>   and bwrite. (NULL means they are not there)  they work like device read
>   and write, only with bytes instead of longs.  (btw there are 3 longs
>   reserved in DEVDRV now and i can think of atleast 2 more functions to
>   add later, readv and writev...  so extend the struct somehow?)
>   
>   2. if bwrite is there use it instead of write in tty_write (also in
>   bflush, midiws...), if the write is RAW just check for job control and
>   return (*f->dev->bwrite)(f, buf, nbytes);
>    and if bread is there do the same atleast for RAW reads in tty_read.
>   (this includes reading pty masters...)
>   
>   3. add bread and bwrite functions to the pty device.  the slaves output
>   pipe can then be changed to use bytes directly. (i think.  the other
>   direction of course not...)
>   
>   4. add support for CLOCAL, HUPCL, VMIN etc and make _real_ modem devices...
>   with bread/bwrite they finally could get decent thruput without 99% CPU load.
> 
> ...and CTLECHO, I guess we want full termio(s) support, eh?

 ok :)
>   
>    this is just an idea i got and i have no idea if and when i could do
>   all this... :)  but what do you think?
> 
> I kind of like it. The main point being, we want a system call that actually
> reads or writes more than 1 byte at a time for ttys. So doing an Fread of 1K
> on /dev/modem1 does a single call, not 1000 Bconin's...

 yes that would be bread.  the new modem devices bread would get a RAW
1k read as that, maybe go to sleep until there is >= VMIN bytes data and
then just do 1 or 2 bcopy()s out of the ports receiver buffer right into
the reading processes memory.  no extra moving data around, no multiple
device read calls, can't get any faster...

>  I would like to see
> these new read and write functions replace Bconin/Bconout, with Bcon* just
> being a special-case (single-character) of them.
> 
> I would suggest that a better way to handle this would be to continue
> supporting the 4 bytes per character, but have an additional flag bit which
> indicates whether or not the caller is interested in the 3 extra bytes. If not,
> just perform the data copy by incrementing the pointer by 4 instead of by 1...

 hmm i think i did not make that clear, the devices `old' 4-byte
read/write functions would still be there and working, and a Bconin
would still end up as one and can get 32 bit.  only MiNT >= version x
would use bread/write for Fread/write on devices where they are != 0.

 doing this with a flag would introduce compatibility problems with
old devices i think... (ok, depends on how you do it.)  and incrementing
the pointer by 4 instead of 1 would still need expanding/collapsing data
into an extra buffer at least once for each Fread/write (and split up
the read/write into chunks not bigger than this buffer, etc...) and it
would still take longer than a device with just bcopy.

 more comments?  (Eric?)

 cheers
	Juergen
-- 
J"urgen Lock / nox@jelal.north.de / UUCP: ..!uunet!unido!uniol!jelal!nox
								...ohne Gewehr
PGP public key fingerprint =  8A 18 58 54 03 7B FC 12  1F 8B 63 C7 19 27 CF DA