From owner-freebsd-hackers Wed Feb 10 08:30:37 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA18603 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 08:30:37 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA18591 for ; Wed, 10 Feb 1999 08:30:34 -0800 (PST) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id JAA09410; Wed, 10 Feb 1999 09:30:20 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp01.primenet.com, id smtpd009282; Wed Feb 10 09:30:15 1999 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id JAA08698; Wed, 10 Feb 1999 09:30:06 -0700 (MST) From: Terry Lambert Message-Id: <199902101630.JAA08698@usr07.primenet.com> Subject: Re: portability of shm, mmap, pipes and socket IPC To: peter@netplex.com.au (Peter Wemm) Date: Wed, 10 Feb 1999 16:30:05 +0000 (GMT) Cc: tlambert@primenet.com, kuku@gilberto.physik.RWTH-Aachen.DE, hackers@FreeBSD.ORG In-Reply-To: <199902100403.MAA55849@spinner.netplex.com.au> from "Peter Wemm" at Feb 10, 99 12:03:43 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > FreeBSD fails to support fcntl's on sockets: F_SETOWN, F_GETOWN, F_GETLK, > > F_SETLK, F_SETLKW. This is due to the use of struct fileops, > > since sockets are not backed by true vnode objects. > > Terry, read the bloody source before spreading unverified FUD like this.. > The fcntl(2) ops F_SETOWN/F_GETOWN are translated into FIOSETOWN/FIOGETOWN > ioctl's and are fully implemented. Sorry; I didn't realize that someone had kludged this to "work" after the last time someone complained about it not working. > However, as you point out, the fcntl() > (and flock()) *locking* operations are not implemented. IMHO file locking > on a socket is of pretty marginal value since there is no seek space > (with the possible exception of using it for a mutex instead of using > sendmsg() or something sensible). Yeah; the putative utility isn't really at issue, though, only whether it works on Linux and not on FreeBSD. You could make the same argument about value on SYSV IPC, since it's not select(2)'able. > > > pipes - ? named pipes? > > > > FreeBSD pipes are bidirectional, since they are implemented with the > > AF_UNIX socket code. > > Rubbish! They are quite seperate to an AF_UNIX socketpair() and have been > for a *long* time (since 1996 when 2.2 was branched). Sorry again; I got confused. It's the IPC code that's implemented with the sys_socket.c's struct fileops referenced by uipc_syscalls.c. > > FreeBSD fails to support fcntl's on pipes: F_SETOWN, F_GETOWN, F_GETLK, > > F_SETLK, F_SETLKW. This is due to the use of struct fileops, > > since pipes are not backed by true vnode objects. > > F_SETOWN/F_GETOWN are implemented as ioctl calls, that part is wrong. > *Only* the file locking parts are not implemented since it's of such little > value with no seek space. Hmmmm. From my reading of the sources, this is actually a fairly recent addition (November 11th, 1998, by Truckman). I blame my build environment for that particular lapse. I still don't think the non-existance of a real vs. a virtual seek space is relevent. The obvious way to fix this is to hang the locks off the vnode, and move the advisory locking out of all FS's (except the network clients, of course, which may need to veto lock coelescence if the server refuses the lock). In any case, thanks for the corrections; it all adds to the general knowledge base, which is important, since no one else stepped forward with the information. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message