fouts@AMES-NAS.arpa (08/06/86)
I've just heard the amusing (?) rumor that AT&T is about to change the
SVR2 validation procedure so that systems with Socket() functionallity will
fail, even if they are otherwise in complete compliance.
Anybody know anything about this one?
(Please respond to fouts@ames-nas, as I don't normally read these
lists.)
Thanks,
Martyron@BRL.ARPA (Ron Natalie) (08/07/86)
Well, one point is that fstat doesn't work right on systems that use sockets to support the PIPE system call. -Ron
csg@pyramid.UUCP (Carl S. Gutekunst) (08/09/86)
In article <2846@brl-smoke.ARPA> ron@BRL.ARPA (Ron Natalie) writes: >Well, one point is that fstat doesn't work right on systems that use >sockets to support the PIPE system call. Um, not necessarilly. Pyramid OSx implements SV pipes using sockets, and the SV fstat() works perfectly. (Believe me, I know; the 4.2bsd fstat() doesn't distingush between pipes and sockets, so I had a BSD program calling the SV fstat() so it could determine which was which....) I really don't believe the rumor that AT&T will reject machines that have sockets *anywhere*, but I *DO* believe the validation suite will check for correctness on fstat(). Waving a red flag in front of the bull again, :-) I'd bet that Sun's Unix 3.2 does the fstat() correctly for SV, too, and they also have pipes on sockets. <csg>
guy@sun.uucp (Guy Harris) (08/09/86)
From the original article: > I've just heard the amusing (?) rumor that AT&T is about to change the > SVR2 validation procedure so that systems with Socket() functionallity will > fail, even if they are otherwise in complete compliance. That rumor sounds incredibly bogus. 1) How the hell are they going to discover if you support sockets? 2) Since the Woolongong TCP/IP package for the 3Bs running S5R2 provides a library that emulates the socket calls, it seems unlikely that they would a) want to or b) could get away with anathematizing them. From the first response: > Well, one point is that fstat doesn't work right on systems that use > sockets to support the PIPE system call. It can be made to do so with relatively little pain. 4.3 already ensures that the dev/inumber pair is unique, and stuffs a reasonable block size into "st_blksize"; the other reasons for doing an "fstat" might be 1) to see if the "st_mode" field says it's of type S_IFIFO, which can work if you stuff S_IFIFO|<permissions> into "st_mode", and 2) to see how much data is unread in the pipe by reading "st_size", which can work if you stuff so->so_rcv.sb_cc into "st_size". (I believe the feature in 2) may date back to V7, and thus would have worked in 4.1BSD as well if 32V had it also.) Alternatively, you could use something other than sockets to implement pipes.... -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
stew@hanauma.UUCP (Stewart Levin) (08/10/86)
................................................................ I missed the beginning of this discussion, but for BSD Unix I never found any 100% sure-fire way of using fstat(2) to detect a pipe. The best I ever did was about 95% accuracy. To get 100% accuracy under 4.1BSD I cribbed a trick from tee(1) of lseek'ing on the file descriptor and checking for an ESPIPE error. 4.2 broke this by returning EINVAL but this is fixed in 4.3, I'm told, and also in one of my 4.2 Bug Reports distributed on the 84.2 Usenix tape. Now I'm just waiting for Convex's next system release.... ... decvax!hanauma!stew
gwyn@brl-sem.ARPA (Doug Gwyn ) (08/11/86)
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.