Re: Unit number allocation API
From: Poul-Henning Kamp (phk_at_phk.freebsd.dk)
Date: 09/30/04
- Previous message: John Baldwin: "Re: Unit number allocation API"
- In reply to: John Baldwin: "Re: Unit number allocation API"
- Next in thread: Poul-Henning Kamp: "Re: Unit number allocation API"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: John Baldwin <jhb@FreeBSD.org> Date: Thu, 30 Sep 2004 20:57:57 +0200
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. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
- Previous message: John Baldwin: "Re: Unit number allocation API"
- In reply to: John Baldwin: "Re: Unit number allocation API"
- Next in thread: Poul-Henning Kamp: "Re: Unit number allocation API"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
