Date: Thu, 30 Sep 2004 20:57:57 +0200 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: John Baldwin <jhb@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: Unit number allocation API Message-ID: <48733.1096570677@critter.freebsd.dk> In-Reply-To: Your message of "Thu, 30 Sep 2004 14:09:25 EDT." <200409301409.25904.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200409301409.25904.jhb@FreeBSD.org>, John Baldwin writes: >On Thursday 30 September 2004 03:06 am, Poul-Henning Kamp wrote: >> I had this one out on arch@ previously. I'm very interested in informed >> feedback on how we deal with locking for service api's like this. > >I would suggest that the caller should ask for a unit before it needs a lock >and if it finds that it doesn't need the unit after all it can give it back >in the error handling. That is, this is similar to malloc'ing a structure up >front, then grabbing locks and making changes, then after releasing the lock >free'ing the structure if it turned out we didn't need it. Right. My personal guess is that driver->attach() and driver->probe() will never get out from Giant (I can't seriously see the benefits as being bigger than the effort) and therefore I think the problem of locking API's like this can be wholesale ignored for a very long time. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48733.1096570677>