Date: Thu, 11 Feb 1999 19:32:43 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: peter@netplex.com.au (Peter Wemm) Cc: tlambert@primenet.com, kuku@gilberto.physik.RWTH-Aachen.DE, hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC Message-ID: <199902111932.MAA01698@usr06.primenet.com> In-Reply-To: <199902110807.QAA61681@spinner.netplex.com.au> from "Peter Wemm" at Feb 11, 99 04:07:25 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. > > I wasn't talking about select(), I was talking about *file* locking on > non-files like sockets and pipes. FWIW, it *looks* rather simple to > implement this at a higher level since the kern_lockf.c code is not > actually vnode specific at all. All that it (in theory) needs is for > sockets and pipes to implement an advlock() op entry, fetch their per-pipe/ > socket 'struct lockf *' and call lf_advlock(). lf_advlock() takes a VOP_* > style argument but it doesn't need to, it could just as well take explicit > args. You would need to do more than just that. Specifically, you would need to add an advlock op to the struct fileops, since those three types of descriptors aren't implemented by a VFS. I've suggested soloutions in the past for this, so I won't suggest them again. > My point is, if it was *useful* or *in use*, then somebody would have > implemented it it. Well, we've been asked the question at least three times, by my count, on the -current mailing list, so it's *in use*. That doesn't preclude anyone from declaring that it's not *useful*, of course, since that's always a subjective judgement. > > > 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 looked at the code and it isn't a new feature. What Don Lewis did was > clean up the interfaces a little so that the functionality was tracked > better to prevent SIGIO shootdowns. It's always been done this way (fcntl > translated into an ioctl()), but it used to be done with TIOCSPGRP etc and > now it's done with FIOSETOWN and friends. The functionality is a little > more robust, it's not new. You need to "cvs diff -r 1.44 -r 1.45 -c sys_pipe.c | more". The code was implemented for sockets, but not anything else that used struct fileops. This was an extension to support it on pipes. > > I still don't think the non-existance of a real vs. a virtual seek > > space is relevent. > > Supporting unused features causes bloat. Unless it's actually going to be > useful and maybe even *used* then it's irrelevant. Incidently, I can see > one use for it, and that's to do a mutex of some sort. Imagine a > cooperative process pair that want to get records over a pipe or socket > but the data is written non-atomically in multiple chunks, etc. This is a > bad example though because there are better ways. Right. But "bloat" is a bad example of a reason not to do this, since you could get rid of all the duplicate code in each VFS, and at the same time get rid of the problems with VOP_ADVLOCK stacking, and get rid of the struct fileops entirely. The net amount of code to implement this would be *less* than the amount of code that's in there now. Even if you don't agree that NFS client locking requires a veto based VOP_ADVLOCK, an anti-bloatist can't argue with the reduction of bloat. > > 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). > > This would fix nothing in these cases since sockets and pipes do not *have* > a vnode. > > You've got me bugged now.. I had a quick shot at seeing just how hard it > would actually be to implement locking for pipes and sockets. I was > suprised at how easy it's turning out and (to my suprise) it slightly > tidies a few things up a bit.. Well, if getting you bugged gets code to do something from someone who can commit it.... 8-)... while you are in there, you might want to look at what it would take to put pty's, sockets, pipes, and the IPC system calls into specfs-like VFS's. This would let you get rid of struct fileops entirely, and reduce bloat at the same time. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902111932.MAA01698>