Date: Fri, 7 Aug 1998 01:26:02 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: mcgovern@spoon.beta.com (Brian J. McGovern) Cc: n@nectar.com, joelh@gnu.org, mcgovern@spoon.beta.com, hackers@FreeBSD.ORG Subject: Re: O_SHLOCK and O_EXLOCK - change to layering required? Message-ID: <199808070126.SAA23982@usr06.primenet.com> In-Reply-To: <199808061159.HAA01248@spoon.beta.com> from "Brian J. McGovern" at Aug 6, 98 07:59:46 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >Huh? > > >Sure, O_SHLOCK and O_EXLOCK are advisory, but so are lock files. > >Applications are free to ignore any of them. > > >Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org > > Yeah, but 80% of my problem is the fact they cause the open() call on a device > to fail with varying error codes, depending on the type of device. No it doesn't. All device opens fail with: EOPNOTSUPP >From /sys/miscfs/specfs/spec_vnops.c, spec_advlock(). Before the lock is attempted, the open is attempted (you can call VOP_ADVLOCK() on a vinode until after you have a vnode). So if you are getting a different error, your open() call is failing before it even attempts the lock. The problem here is struct fileops: an open device uses a different struct fileops; it is not a VFS-based implementation of fileops (per the code in /sys/kern/vfs_vnops.c). I actually made this work a while back; the struct fileops is referenced off the vnode pointer for the device (ie: it is one of three vnode types that aren't backed directly by a VFS implementation). The fix involves hanging the advisory locking list off the vnode instead of teh inode. It was part of my patches to support NFS locking (specifically, part of making VOP_ADVLOCK be veto-based). This would mean that there was a data structure associated with the system object instance instead of an alias (in other words, the vnode, not the inode, and not a device open instance specific data structure) that was in common that all implementations, independant of whether a non-standard struct fileops was used. For the coup-de-grace, you would modify VOP_ADVLOCK() in specfs to return 0 (success) -- and not veto the operation by the upper level code (after the non veto, the proposed lock would be coelesced, in accordance to UNIX locking semantics being a two dimensional projection of a three dimensional set of lock relationships; just like when an NFS server didn't veto an NFS clients lock, in my code). 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?199808070126.SAA23982>