From owner-svn-src-all@FreeBSD.ORG Sat Jun 2 13:05:12 2012 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5238B106566B; Sat, 2 Jun 2012 13:05:12 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.freebsd.org (Postfix) with ESMTP id DB44A8FC16; Sat, 2 Jun 2012 13:05:11 +0000 (UTC) Received: from c122-106-171-232.carlnfd1.nsw.optusnet.com.au (c122-106-171-232.carlnfd1.nsw.optusnet.com.au [122.106.171.232]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q52D526f030690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Jun 2012 23:05:04 +1000 Date: Sat, 2 Jun 2012 23:05:02 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Ed Schouten In-Reply-To: <201206021050.q52AoQBQ084298@svn.freebsd.org> Message-ID: <20120602220632.Y1668@besplex.bde.org> References: <201206021050.q52AoQBQ084298@svn.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r236441 - head/lib/libc/sys X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2012 13:05:12 -0000 On Sat, 2 Jun 2012, Ed Schouten wrote: > Log: > Remove invalid remark about pipes. > > The stat structures returned on pipes seems to contain all the > information required by POSIX. Especially the wording "and thus to a > pipe" makes little sense, because it seems to imply a certain > relationship between sockets and pipes that simply isn't there. It is because pipes are implemented in sockets in BSD. FreeBSD changed this in 1996, but fstat(1) still claims it, and I got fstat(1) instead of fstat(2) when I first tried to look this up: % FSTAT(1) FreeBSD General Commands Manual FSTAT(1) % ... % For example, the addresses mentioned above are the addresses which the % ``netstat -A'' command would print for tcp, udp, and unixdomain. Note % that since pipes are implemented using sockets, a pipe appears as a con- % nected unix domain stream socket. A unidirectional unix domain socket % indicates the direction of flow with an arrow (``<-'' or ``->''), and a % full duplex socket shows a double arrow (``<->''). > Modified: head/lib/libc/sys/stat.2 > ============================================================================== > --- head/lib/libc/sys/stat.2 Sat Jun 2 10:14:55 2012 (r236440) > +++ head/lib/libc/sys/stat.2 Sat Jun 2 10:50:25 2012 (r236441) > ... > @@ -431,7 +431,7 @@ system call appeared in > .Sh BUGS > Applying > .Fn fstat > -to a socket (and thus to a pipe) > +to a socket > returns a zeroed buffer, > except for the blocksize field, > and a unique device and inode number. This is still hard to parse. I think it says that fstat(2) returns a zeroed buffer except for a nonzero blocksize field in it, and it returns a unique device and inode number in addition to the buffer, but this makes no sense since fstat(1) only returns one thing. This thing isn't a generic buffer either -- other parts of the man page never use "buffer", and mostly refer to the returned thing formally as "the struct pointed to by sb". The normal informal description is more like "the stat buffer". stat.2 seems to be wrong about the unique device number too. uipc_usrreq.c sets st_blksize and st_ino as documented for the "blocksize" and "inode number" (except st_ino can be non-unique after wraparound at 2**32), but it always sets st_dev to the non-unique value NODEV. Other subsystems are more careful about inventing unique (st_dev, st_ino) ids. Pipes (ab)use devfs_alloc_cdp_inode() for st_dev and alloc_unr() for st_ino. Sockets still use the primitive ++unp_ino except when this wraps to 0, it is incremented again. I prefer the primitive version. 2**32 inode numbers should be enough for anyone :-), and there is no problem letting them grow very large and sparse, unlike for pids and device numbers, so hashing them to give uniqueness is just a waste of time and space. It probably takes a day or two to create 4G of sockets even if you try, and then the chance of a collision is about 1 in 2**32 unless you try. POSIX requires most fields in struct stat including st_dev to be "meaninful" for all POSIX file types including sockets, so the non-unique st_dev is just another thing for this BUGS section. This bug suite was only recently fixed for pipes. It seems to be very easy to fix for st_dev of sockets -- just use a single id reserved for all sockets. NODEV might already work, but only if no other subsystem abuses it and it can't happen in normal use. Or reserve a range of say 2**16 device ids for sockets, and use this to make (st_dev, st_ino) pairs unique for sockets. Nothing requires st_dev to be the same for all sockets, and 2**48 numbers should really be enough for anyone. Bruce