Date: Wed, 7 Feb 2001 21:26:00 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: bp@butya.kz (Boris Popov) Cc: freebsd-arch@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: Re: vnode interlock API Message-ID: <200102072126.OAA24284@usr08.primenet.com> In-Reply-To: <Pine.BSF.4.21.0102061638280.82511-100000@lion.butya.kz> from "Boris Popov" at Feb 06, 2001 05:00:03 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> So, I suggest to introduce two macro definitions which will hide > implementation details for interlocks: > > #define VI_LOCK(vp) mtx_enter(&(vp)->v_interlock, MTX_DEF) > #define VI_UNLOCK(vp) mtx_exit(&(vp)->v_interlock, MTX_DEF) > > for RELENG_4 they will look like this: > > #define VI_LOCK(vp) simple_lock(&(vp)->v_interlock) > #define VI_UNLOCK(vp) simple_unlock(&(vp)->v_interlock) > > Any comments, suggestions ? 1) Macros are good; interfaces are better. I've consistantly recommended that the NFS cookie interface be rewritten to not require cookies, even though the FreeBSD/NetBSD/OpenBSD differences _could_ be masked with macros. The issue is one of binary vs. source compatability. 2) If you are going to wrap vnode handling, it would probably be a good idea to wrap it using the same approach that another OS uses, instead of being gratuitously different in naming. I would suggest using the Solaris names, but I will admit that doing that depends heavily on the semantics being the same (I think they would be). Worst case, pick an OS with the same semantics; if there are none, this may be an opportunity to learn from other OSs _why_ they don't have the same semantics. 3) It seems to mee that the additional parameter of MTX_DEF is gratuitous, and tries to stretch mutex semantics further than they should be stretched. I personally would have no problem with the conversion of simple_{un}lock() into the equivalent mtx_*() calls. Even if the MTX_DEF can not be murdered without a large public outcry, using this as the the default demantic for the simple_*() equivalents isn't really a bad idea, in my book, and could be done with inline wrappers. Best case, one could apply the WITNESS code to debugging 4.x problems, with some work. 4) You need to wrap the calls with "{ ... }"; this is because it may be useful in the future to institute turnstile or single wakeup semantics, and converting the macro into a single statement instead of a statement block would mean a potentially large amount of work would be needed to cope with the change later, whereas, you seem to plan to already need to touch all those spots now. Again, the Solaris SMP vnode lock management macros are, I think, a good example (or at least they were, six years ago, when Solaris faced the same problem). I have other comments, but these are the four most important ones, IMO, and I've been making a conscious effort to not clutter arguments by giving more detail than people seem to want to hear before they overflow and tune out. 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-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102072126.OAA24284>