Unit number allocation API

Poul-Henning Kamp phk at phk.freebsd.dk
Thu Sep 30 11:58:05 PDT 2004

In message <200409301409.25904.jhb at 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.


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

Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at 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.

More information about the freebsd-current mailing list