Re: pipes & ptys

[itschere@techfak.uni-bielefeld.de]

Howard Chu <hyc@hanauma.jpl.nasa.gov> writes:

> A simple shell would just use cooked mode and read a line at a time, not
> single-character, btw...

Maybe the shell, but not my imaginary window manager. If it waits for each
newline, screen output will look pretty poor... :-(

> Just a note to TeSche - the 1 byte I/Os are converted to 4 bytes to allow
> pty's to pass scan code and shift status info, just like Bconin from console.

Looking at the code, I discovered that recently. Point is that it - more or
less - doesn't matter if my 1000 1 byte fread calls get expanded to 100 4 bytes
fread calls. It looks like waiting with fselect(m,0,0,0) (thanks Eric!) and
than read all that is there with one fread call is the best idea at the
moment. I'll look at it, but for now I presume finstat() really reports the
number of bytes in a pipe. So at least my reading program will not be the
bottleneck, if the writing one choses to write in 1 byte chunks, I loose...

> 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... 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.

Looks like this is what I _really_ wanted to say... :-)

But what we _really_ want is a extra device driver for each modem device that
outputs/reads characters driven by interrupt, so the whole Bcon*() stuff gets
obsolete. So you won't need an extra system call, but just a new device
driver for the biosfs...

Perhaps I'll start playing with this idea in some future, it's just that I
expect great difficulties with existing programs, since they MUSTN'T use the
bcon*() calls any more... :-(

bye,
TeSche