15 Aug
2016
15 Aug
'16
2:04 p.m.
From: Warren Toomey
xv6 is a Unix-like OS written for teaching purposes.
I'm fairly well-aware of Xv6; I too am planning to use it in a project.
But back to the original topic, it sounds like there's a huge amount of
variance in the semantics of doing fstat() on a pipe. V6 doesn't special-case
it in any way, but it sounds as if other systems do.
What V6 does (to complete the list) is grow the temporary file being used to
buffer the pipe contents up to a certain maximum size, whereupon it halts the
writer, and waits for the reader to catch up - at which point it truncates
the file, and adjusts the read and write pointers back to 0. So fstat() on
V6, which doesn't special-case pipes in any way for fstat(), apparently
returns 'waiting_to_be_read' plus 'already_read'.
>> xv6 has fstat() but returns an error if the
file descriptor isn't
>> associated with an i-node.
> ?? All pipe file descriptors should have an inode?
To answer my own question, after a quick look at the Xv6 sources (on my
desktop ;-); it turns out that Xv6 handles pipes completely differently;
instead of borrowing an inode, they have special 'pipe' structures. Hence the
error return in fstat() on Xv6. (That difference also limits the amount of
buffered data in a pipe to 512 bytes. So don't expect high throughput from a
pipe on Xv6! :-)
So I guess you get to pick which semantics you want fstat() on a pipe to have
there: V6's, V7's (see below), or something else! :-)
7th Ed seems to return the amount of free space in the
pipe, if I read
the code correctly:
I'm not sure of that (see below), but I think it would make more sense to
return the amount of un-read data (which is what I think it does do), as the
closest semantics to fstat() on a file.
It might also make sense to return the amount of free space (to a writer), and
the amount of data available to read (to a reader), since those are the
numbers users will care about. (Although then fstat() on the write side of a
pipe will have semantics which are inconsistent with fstat() on files. And if
the user code knows the maximum amount of buffering in a pipe, it could work
out the available write space from that, and the amount currently un-read.)
fstat()
{
...
/* Call stat1() with the current offset in the pipe */
stat1(fp->f_inode, uap->sb, fp->f_flag&FPIPE? fp->f_un.f_offset: 0);
}
stat1()
{
...
ds.st_size = ip->i_size - pipeadj;
I'm too lazy to go read the code (even though I already have it :-), but V7
seems to usually be very similar to V6. So, what I suspect this code does is
pass the expression:
((fp->f_flag & FPIPE) ? fp->f_un.f_offset : 0)
as 'pipeadj' (to account for the amount that's already been read), and then
returns (ip->i_size - pipeadj), i.e. the amount remaining un-read, as the
size.
Noel
15 Aug
15 Aug
3:14 p.m.
New subject: fstat(2) on pipes?
On Mon, Aug 15, 2016, at 10:04, Noel Chiappa wrote:
But back to the original topic, it sounds like
there's a huge amount
of variance in the semantics of doing fstat() on a pipe. V6 doesn't
special-case it in any way, but it sounds as if other systems do.
I expect that the single important thing, the only thing that most
applications will rely on, is it returning successfully and indicating
that the file type is fifo. If your version of xv6 supports file
permissions and if pipes are one-way it may be worthwhile to indicate
which end of the pipe it is.
In the standard: the use of the size field is explicitly unspecified for
pipes - for any file type other than regular files, symbolic links, and
shared/typed memory objects. Other than that, it's clear from the
standard that it's intended to succeed and report a sensible file type
for non-filesystem objects like pipes, shared memory objects, and
sockets. However, there's no discussion of what, if anything, belongs in
the dev/inode*, permissions, nlink, and timestamps.
On Linux: st_dev is a device number specific to pipes and st_ino is a
unique inode number. I haven't tested the timestamps thoroughly (my test
only covered instantaneously opening and statting a pipe), but they are
valid timestamps rather than being 0 or -1 or some garbage value.
st_uid/gid are [probably, haven't tested complicated cases] the user
that created it, st_nlink is 1, and the permissions are set to
[user-only] the read or write mode the pipe is opened in.
*Though, the standard's light on the meaning of device identifiers in
the first place, and what it does say could easily be read as demanding
a unique device/inode pair regardless of the nonexistence of a physical
device, which naturally leads to the solution that I observed on Linux
and that someone else mentioned on OSX.
4:56 p.m.
New subject: fstat(2) on pipes?
On 15 Aug 2016 11:14 -0400, from random832(a)fastmail.com (Random832):
On Mon, Aug 15, 2016, at 10:04, Noel Chiappa wrote:
On Linux/glibc, based on the fstat(2) man page, it looks like the size
field is undefined for a FIFO:
But back to the original topic, it sounds like
there's a huge amount
of variance in the semantics of doing fstat() on a pipe. V6 doesn't
special-case it in any way, but it sounds as if other systems do.
I expect that the single important thing, the only thing that most
applications will rely on, is it returning successfully and indicating
that the file type is fifo. The st_size field gives the size of the file (if it is
a regular
file or a symbolic link) in bytes. The size of a symbolic link is
the length of the pathname it contains, without a terminating null
byte.
The mode field is used to hold the type of file:
The following POSIX macros are defined to check the
file type using
the st_mode field:
...
S_ISFIFO(m) FIFO (named pipe)?
...
The following flags are defined for the st_mode field:
...
S_IFIFO 0010000 FIFO
...
The above from Debian Wheezy.
--
Michael Kjörling • https://michael.kjorling.se • michael(a)kjorling.se
“People who think they know everything really annoy
those of us who know we don’t.” (Bjarne Stroustrup)
3223
days inactive
3223
days old
2 comments
3 participants
participants (3)
-
jnc＠mercury.lcs.mit.edu -
Michael Kjörling -
Random832