composer@bucsf.bu.edu (Jeff Kellem) (03/12/90)
From the UMAX4.2 fstat(2) man page... When fd is associated with a pipe, fstat reports an ordinary file with an inode number, restricted permissions, and a possibly meaningless length. Ok, that's understandable. But, it doesn't say what st_blksize should be. From the pipe(2) man page, one can infer that this value SHOULD be 4096, since "up to 4096 bytes of data are buffered before the writing process is suspended", and since st_blksize is supposed to be the optimal blocksize for I/O operations. On the otherhand, realizing that the pipe(2) system call is really implemented via socketpair(2), and noticing that in the RESTRICTIONS section of the fstat(2) man page, it states: Applying fstat to a socket returns a zeroed buffer. then we have a contradication in the fstat man page. Unless, of course, fstat is able to magically determine that the fd connected to this socket was created via pipe(2) and will return some real data instead of zeroing out the buffer. Unfortunately, when fstat-ing a file descriptor (fd) that is connected to a pipe, st_blksize gets set to zero, when (in my opinion) it should be set to 4096. I also did a quick check on the value of st_ino and st_mode when the fd is a pipe. They seem to be set to zero. It looks as though the stat buffer might be getting zeroed out from the fstat call (since pipes are really implemented using the socketpair(2) call). So, does fstat actually put any information into the stat buffer when the fd is a pipe? If it doesn't, considering that the pipe is using sockets, then maybe this should be noted in the UMAX4.3 man pages, before release. Though, I would PREFER that fstat return some useful information when the fd is connected to a pipe, especially the st_blksize field, as it does on other unix OS'. Hope this made sense. It's hard to tell at 2:30am... Thanks for any information regarding this... -jeff Jeff Kellem INTERNET: composer@cs.bu.edu (or composer@bu.edu) UUCP: ...!harvard!bu-cs!composer
jb@CS.BROWN.EDU (03/14/90)
What you are seing is an artifact of 4.2BSD. 4.3BSD changed fstat to return the buffer size associciated with the socket. I'd assume that UMAX4.3 will have this fix when it comes out. Jim Bloom
isaac@goanna.oz.au (Isaac Balbin) (03/14/90)
jb@CS.BROWN.EDU writes: >I'd assume that >UMAX4.3 will have this fix when it comes out. Speaking of which, has anyone heard when this is likely to occur (UMAX4.3)?
corbin@maxzilla.Encore.COM (03/17/90)
In article <COMPOSER.90Mar12024415@bucsf.bu.edu> composer@cs.bu.edu writes: >From the UMAX4.2 fstat(2) man page... > > When fd is associated with a pipe, fstat reports an ordinary file with > an inode number, restricted permissions, and a possibly meaningless > length. This is wrong. The documentation is in error. >Ok, that's understandable. But, it doesn't say what st_blksize should be. >From the pipe(2) man page, one can infer that this value SHOULD be 4096, >since "up to 4096 bytes of data are buffered before the writing process is >suspended", and since st_blksize is supposed to be the optimal blocksize >for I/O operations. Umax 4.2 and BSD 4.2 zero out the statistics buffer and return. No status is passed back on pipes. Umax 4.3 beta currently does the same. BSD 4.3 returns something on the order of "so_snd.sb_hiwat + so_rcv.sb_cc". >On the otherhand, realizing that the pipe(2) system call is really >implemented via socketpair(2), and noticing that in the RESTRICTIONS >section of the fstat(2) man page, it states: > > Applying fstat to a socket returns a zeroed buffer. > >then we have a contradication in the fstat man page. Unless, of course, >fstat is able to magically determine that the fd connected to this socket >was created via pipe(2) and will return some real data instead of zeroing >out the buffer. Pipes starting in Umax 4.3 will no longer be based upon sockets. The code was rewritten for performance reasons. Using sockets semantics is a no-no on pipes. Anyone who currently has code under Umax4.2 that relies on socket semantics will be in for a surprise under Umax 4.3. >Unfortunately, when fstat-ing a file descriptor (fd) that is connected to a >pipe, st_blksize gets set to zero, when (in my opinion) it should be set to >4096. I also did a quick check on the value of st_ino and st_mode when the >fd is a pipe. They seem to be set to zero. It looks as though the stat >buffer might be getting zeroed out from the fstat call (since pipes are >really implemented using the socketpair(2) call). > >So, does fstat actually put any information into the stat buffer when the >fd is a pipe? If it doesn't, considering that the pipe is using sockets, >then maybe this should be noted in the UMAX4.3 man pages, before release. > >Though, I would PREFER that fstat return some useful information when the >fd is connected to a pipe, especially the st_blksize field, as it does on >other unix OS'. > >Hope this made sense. It's hard to tell at 2:30am... > >Thanks for any information regarding this... The current Umax 4.3 beta code simply zeroes out the statistics buffer as previous Umax 4.2 and BSD 4.2 kernels have done. I will change the Umax 4.3 pipe code to pass back status. I would like to ask everyone what would be their choice on how this is done. Here is the code fragment I am about to put in as a result of this discussion: pipe_stat (pb, ub) struct pbuf *pb; struct stat *ub; { /* * Zero the statistics buffer. */ bzero((char *)ub, sizeof(*ub)); % /* % * Pass something useful back. % */ % ub->st_dev = NODEV; % ub->st_blksize = pb->pb_size; /* pipe buffer size */ % ub->st_size = pb->pb_cc; /* character count */ return(ESUCCESS); } The % lines show the new code I am adding. st_blksize will get set to the length of the pipe buffer while st_size will reflect the number of characters used in the buffer. The number of bytes available for reading is "st_size" and the number of bytes available for writing without blocking are "st_blksize - st_size". Any comments? Steve Corbin, OS Development, Encore Computer Stephen Corbin {bu-cs,decvax,necntc,talcott}!encore!corbin corbin@encore.COM