Date: Wed, 1 Jan 2003 16:54:17 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: "Brian F. Feldman" <green@FreeBSD.org> Cc: Nate Lawson <nate@root.org>, Alan Cox <alc@FreeBSD.org>, <cvs-all@FreeBSD.org>, <cvs-committers@FreeBSD.org> Subject: Re: cvs commit: src/sys/vm vm_map.c vm_map.h Message-ID: <20030101163629.O55844-100000@gamplex.bde.org> In-Reply-To: <200212312121.gBVLLKNX013666@green.bikeshed.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 31 Dec 2002, Brian F. Feldman wrote: > Nate Lawson <nate@root.org> wrote: > > On Tue, 31 Dec 2002, Alan Cox wrote: > > > [...] > > > - lockmgr(&map->lock, LK_RELEASE, NULL, curthread); > > > + if (map->system_map) > > > + _mtx_unlock_flags(&map->system_mtx, 0, file, line); > > > + else > > > + lockmgr(&map->lock, LK_RELEASE, NULL, curthread); > > > } > > > > > > void > > > > Please use the non-underscore, exported mtx_* routines. The macros expand > > to the same thing unless you're doing something strange w/ file and line > > (but I don't see that in your patch). > > They're in-line functions, so the file and line numbers are entirely useless > if you don't pass them in directly, and used the macros. That would be another bug (if they were inline functions), but they are actually ordinary functions which are passed file and line args. In other words, they do do something strange w/ file and line. It may be another bug that they don't do something strange with __func__ -- the function name is for the ordinary function, not the caller, so it is unrelated to the file and line and not very interesting. This is part of the bug that file and line are only used for the mtx locks. They are not used for lockmgr locks or passed to KASSERT()s. KASSERT() uses __FILE_ and __LINE_ internally but we pass __func__ to it. The mtx macros are more flexible and pessimized. Until this commit, most things used lockmgr locks and file and line were mostly unused. I really dislike passing around file, line, __FILE__, __LINE__ and __func__. They can be determined from the program counter in most cases given some debugging info. Passing them unconditionally pessimizes even cases where they aren't used (when INVARIANTS is not configured, etc), and passing them conditional on debugging options gives complications (see sys/mutex.h). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030101163629.O55844-100000>