Date: Fri, 24 Nov 2000 01:46:27 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: bp@butya.kz (Boris Popov) Cc: tlambert@primenet.com (Terry Lambert), freebsd-fs@FreeBSD.ORG Subject: Re: MSDOS FS and flock? Message-ID: <200011240146.SAA06289@usr06.primenet.com> In-Reply-To: <Pine.BSF.4.21.0011230754540.61472-100000@lion.butya.kz> from "Boris Popov" at Nov 23, 2000 08:06:39 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> > Well, ignoring the fact that "vop_std*" takes the decision out > > of the authors hands... ;^) > > No, it doesn't - presence of vop_std* functions doesn't mean that > they are included in the default VOPs. And even in the later case, after > is free to overload them. You are right, that I was talking about the defaults. I made the assumption that, if a standard mechanism was provided, that it would quickly find itself in the defaults. It's a chicken-and-egg problem: to get rid of them, you have to know they are there. It's actually worse than that, though. If I have NFS, I want to assert the lock locally, so that I don't generate traffic: I am now back in the business of reimplementing the default VOP in the NFS VOP, so that I can have both the NFS behaviour and the local assertion, simultaneously. You could argue that the extra NFS traffic was the price of using NFS. But the issue is more complicated than that, when I introduce a stacking layer. If I have a stacking layer that adds two files together, then I may have a lock that crosses the boundary. If I have a stacking layer that is exposed in the filesystem namespace, and the layer stacked below it is also exposed, then I want the upper layer to honor locks that are asserted against the lower layer, independent of the upper layer: these lock lists are on different vnodes. I can make this work for the lower layer honoring the upper, by having the upper layer assert locks on the lower before granting them on the upper. Going the other way is a matter of holding the lower layer vnode over the assertion, so that a lower layer assertion can't progress. All of these things say that the system call wants to operate on a vnode itself, and call VOP_ADVLOCK in the underlying code -- not to make the assertion, but to permit the assertion to propagate, if necessary, and to permit the lower layer to veto the completion of the operation in the upper layer, if the lower layer can not/will not permit the propagation and/or lower level assertion. > > Ugh. Software does not evolve. It is designed, and it is > > "Ugh" - don't take things too literally. I'm pretty aware of the > stages included in the software development processes, but sometimes > choose incorrect terms in the non-native language :) Sorry; I have a hard time distinguishing between that, and a religious zealot who has bought into "The Cathedral and the Bazaar". 8-). 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-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011240146.SAA06289>