Rumor about AT&T Validation (really, pipes in the modern world)

[Doug Gwyn]

All this talk about what fstat() returns for pipes reminds me:

It appears that SVR3 has implemented streams only so far as they
were needed for networking, in much the same r^ole as Berkeley sockets.
The concept of streams, though, is considerably more general, and
one hopes that AT&T will convert all the character I/O subsystem to
streams in a future release.  I mention here some of what remains to
be done:

The pipe() system call needs to return a coupled pair of stream
heads; there may have to be a small protocol module automatically
slipped in to handle generation of SIGPIPE.  This module may also
have to handle the O_NDELAY pipe/FIFO kludge that UNIX System V
is saddled with.  Processes needing to get hold of both ends of a
stream could then use pipe() and pop off these extra modules.
(In SVR3, the only way to get hold of a stream is to open a device
that is known to the kernel to have a "streams driver"; then one
gets only one end of the resulting stream.  AT&T seems to have
made "stream heads" appear different from "stream ends"; if so,
this is a serious design error that should be repaired.  Overall,
SVR3 streams are much more complicated than one would have wished.)

The "terminal handler" part of the terminal drivers needs to be
split off into a "terminal line discipline" protocol module, and
a small addition made to getty to slip the appropriate module
into the stream resulting from opening the raw terminal port.
(What about /dev/tty, you ask?  8th Ed. UNIX opens this on fd 127.)

This stuff should be well-known to those who have been following
Ritchie's work on streams, but it isn't immediately obvious that
AT&T will complete the character I/O system rewrite unless there
is customer pressure to do so.  (Again, we're their REAL customers,
not the end-users who can't tell an "as" from /dev/null.)

Here is what the implementations I know of so far return for fstat();
first, however, here's a table of st_mode file-type definitions:

#define	S_IFMT	0170000			/* type of file: */
#define		S_IFIFO	 0010000	/* FIFO (SysV) */
#define		S_IFCHR	 0020000	/* character special */
#define		S_IFMPC	 0030000	/* mpx character special (V7, obs.) */
#define		S_IFDIR	 0040000	/* directory */
#define		S_IFBLK	 0060000	/* block special */
#define		S_IFMPB	 0070000	/* mpx block special (V7, obs.) */
#define		S_IFREG	 0100000	/* regular */
#define		S_IFLNK	 0120000	/* symbolic link (4BSD, V8) */
#define		S_IFSOCK 0140000	/* socket (4BSD) */

(Fortunately, in spite of the fact that the developers seem not to
communicate well enough with each other, there aren't any conflicts
in these among the current major UNIX variants.)

The value returned for a pipe on various implementations around here is:
4.2BSD, 4.3BSD, UTX/32	0		/* clearly wrong */
JHU PDP-11 UNIX		S_IFREG		/* "ripped-off inode" */

A sensible alternative for a pipe on a real System V kernel would be:
SysV?			S_IFIFO		/* acts the same as a FIFO */

A sensible alternative for a pipe on a Berkeley-socket kernel would be:
socket-kernel?		S_IFSOCK	/* really, socketpair */

The most sensible choice for a pipe on a streams-based kernel seems to be:
streams-kernel?		S_IFCHR		/* like the stream-end */
(I can't figure out what 8th Edition UNIX decided to do for this.)

If there has to be yet another S_IFMT entry for streams, there are
five or six choices left; perhaps the S_IFSOCK value could be stolen
for streams, especially if sockets are emulated using streams.

I would like to hear what implementors (especially AT&T UNIX
developers) are doing about this.  This is an important item to
get our act together on, before everyone runs off in a different
direction again.