Path: sparky!uunet!olivea!mintaka.lcs.mit.edu!bloom-picayune.mit.edu!daemon
From: ent...@ee.WPI.EDU (Lawrence C. Foard)
Newsgroups: alt.os.linux
Subject: tubes
Message-ID: <1992Feb4.123601.4700@athena.mit.edu>
Date: 4 Feb 92 12:36:01 GMT
Sender: dae...@athena.mit.edu (Mr Background)
Reply-To: ent...@ee.WPI.EDU (Lawrence C. Foard)
Organization: The Internet
Lines: 39
I decided to call the IPC stuff tubes, its similar to sockets but much
simpler. A few questions about preferences:
The standard linux pipes always return with the read buffer full except
when the pipe has been closed on the writting end. This works well for
one way pipes but doesn't work for server/client communications where
you have requests and responces going back and forth. Here are a few things
I'm wondering about.
Read has several possibilities:
1) Return only data in the buffer unless there is none then block (unless
O_NONDELAY is on).
2) Try to read as much as one write call produced even if it doesn't fit
in the buffer. This is rather messy since it has to keep track of where
write calls ended.
3)Have it default to #1 and have an IOCTL to switch it back to totally
fullfilling each read request when possible.
I'm leaning toward 3 at this point, since this will work with the line
based I/O that most demons expect. Demons expecting fixed sized data can
switch it to the other mode. Does any one know of programs that would
have problems with this?
Write also has several possibilities:
1) Write all data requested unless the pipe breaks, if O_NONDELAY then
it will just write what will fit in the buffer.
2) Always write only what will fit in the buffer unless it is 0 then block.
I'm leaning toward 1 at this point, can any one see any reason why #2 would be
better?
(am I write in assuming O_NONDELAY is the same as FNDELAY?)
I've got a system call tube(fd[2],type) working which creates a bidirectional
connection and returns the descriptors for each end. type can be the following
TU_STREAM- bidirectional stream
TU_RANDOM- random access requests passed on the server (lseek works)
TU_FS- file system requests passed on to server
TU_FIFO- a plain old fifo (same as pipe(fd[2]))
[possibly another type designed for datagrams]
Currently only TU_STREAM is implemented. The next stage is making this work
when a tube special file is opened. Does any one know where I can get the
source to ls, mknod etc, I didn't see these utilities in the tsx-11 archives
and I will need to patch them.
Newsgroups: alt.os.linux
Path: sparky!uunet!decwrl!usenet.coe.montana.edu!nntp.uoregon.edu!euclid!haertel
From: hae...@euclid.uoregon.edu (Mike Haertel)
Subject: Re: tubes
Message-ID: <1992Feb4.184650.17454@nntp.uoregon.edu>
Originator: haertel@euclid
Sender: ne...@nntp.uoregon.edu
Organization: Department of Mathematics, University of Oregon
References: <1992Feb4.123601.4700@athena.mit.edu>
Date: Tue, 4 Feb 92 18:46:50 GMT
In article <1992Feb4.1...@athena.mit.edu>
ent...@ee.WPI.EDU (Lawrence C. Foard) writes:
>The standard linux pipes always return with the read buffer full except
>when the pipe has been closed on the writting end. This works well for
Reads on standard Unix pipes always return right away if one or more
characters are available, without necessarily satisfying the whole read.
I've tried this at least on System V.2, 4.3 BSD, and research v10.
If Linux pipes don't work this way, they're broken.
>one way pipes but doesn't work for server/client communications where
>you have requests and responces going back and forth. Here are a few things
>I'm wondering about.
>Read has several possibilities:
> 1) Return only data in the buffer unless there is none then block (unless
> O_NONDELAY is on).
> 2) Try to read as much as one write call produced even if it doesn't fit
> in the buffer. This is rather messy since it has to keep track of where
> write calls ended.
> 3)Have it default to #1 and have an IOCTL to switch it back to totally
> fullfilling each read request when possible.
I think the most useful way to have tubes work would be to preserve
write boundaries on reads. I.e., if the writer writes 10 bytes, the
reader would get only ten bytes. Among other things, this makes it
possible to write "eof"s by writing 0 bytes. Useful when pretending
to be a terminal.
>I'm leaning toward 3 at this point, since this will work with the line
>based I/O that most demons expect. Demons expecting fixed sized data can
>switch it to the other mode. Does any one know of programs that would
>have problems with this?
Very few programs in Unix have trouble with this (default, and unchangable)
behavior in Unix pipes. The reason is the stdio library takes care of
dealing with partially fulfilled reads in the proper way. Such programs
can just use fread() and they'll work properly.
>Write also has several possibilities:
> 1) Write all data requested unless the pipe breaks, if O_NONDELAY then
> it will just write what will fit in the buffer.
> 2) Always write only what will fit in the buffer unless it is 0 then block.
>I'm leaning toward 1 at this point, can any one see any reason why #2 would be
>better?
I think it would be even better to try to preserve "write boundaries"
no matter how large the writes are. Difficult, though.
>TU_FS- file system requests passed on to server
Does this mean file system requests are turned into formatted data messages,
and then passed to the server as a sort of remote procedure call? Sounds
like a really good idea.
Path: sparky!uunet!mcsun!news.funet.fi!hydra!klaava!torvalds
From: torv...@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: alt.os.linux
Subject: Re: tubes
Message-ID: <1992Feb5.124413.7796@klaava.Helsinki.FI>
Date: 5 Feb 92 12:44:13 GMT
References: <1992Feb4.123601.4700@athena.mit.edu>
<1992Feb4.184650.17454@nntp.uoregon.edu>
Organization: University of Helsinki
Lines: 23
In article <1992Feb4.1...@nntp.uoregon.edu>
hae...@euclid.uoregon.edu (Mike Haertel) writes:
>In article <1992Feb4.1...@athena.mit.edu>
>ent...@ee.WPI.EDU (Lawrence C. Foard) writes:
>>The standard linux pipes always return with the read buffer full except
>>when the pipe has been closed on the writting end. This works well for
>
>Reads on standard Unix pipes always return right away if one or more
>characters are available, without necessarily satisfying the whole read.
>I've tried this at least on System V.2, 4.3 BSD, and research v10.
>
>If Linux pipes don't work this way, they're broken.
Yeah, they are broken in 0.12: they are fixed in my current version. It
was a very easy fix, I just didn't know the correct behaviour. 0.13 will
also have working O_NDELAY on pipes.
>I think it would be even better to try to preserve "write boundaries"
>no matter how large the writes are. Difficult, though.
Difficult, and non-standard. Why bother? Emulating tty's with pipes is a
bad idea anyway (writing 0 bytes to get "eof") as there are pty's that
do the job better.
Linus
Newsgroups: alt.os.linux
Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!jvnc.net!yale.edu!
yale!mintaka.lcs.mit.edu!bloom-picayune.mit.edu!daemon
From: ent...@ee.WPI.EDU (Lawrence C. Foard)
Subject: tubes
Message-ID: <1992Feb5.181507.10233@athena.mit.edu>
Sender: dae...@athena.mit.edu (Mr Background)
Reply-To: ent...@ee.WPI.EDU (Lawrence C. Foard)
Organization: The Internet
Date: Wed, 5 Feb 1992 18:15:07 GMT
Lines: 23
It appears from the responces I got that the ability to read the amount that
was written is important. I figured out a way of doing this fairly nicely so
you will have the following options for the "tubes":
TU_NO_BUFF the amount read on a call will always be the amount written unless
the buffer isn't big enough (you have the option for it to return
an error in this case). Any suggestions for a better name, it is
buffered but doesn't look like it to the user :)
TU_SEMI_BUFF works like BSD pipes, reads return with what ever is in the
buffer or block and wait if its empty.
TU_FULL_BUFF works like Linux pipes where it always returns the full amount
requested until the other end of the pipe is closed.
modifiers:
TU_RNONBLOCK reads returns the amount in the buffer, or -1 if empty, doesn't
wait.
TU_WNONBLOCK write writes the amount that will fit in the buffer and returns.
The default is semi buffered since it will work correctly when connecting to
text based demons, and has less overhead than "non buffered".
s