Date: Wed, 23 May 2001 16:52:58 +0100 From: Brian Somers <brian@Awfulhak.org> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: Brian Somers <brian@Awfulhak.org>, freebsd-arch@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: RFC: unit_list routines Message-ID: <200105231552.f4NFqwF05688@hak.lan.Awfulhak.org> In-Reply-To: Message from Garrett Wollman <wollman@khavrinen.lcs.mit.edu> of "Wed, 23 May 2001 11:23:32 EDT." <200105231523.LAA29635@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> <<On Wed, 23 May 2001 09:15:41 +0100, Brian Somers <brian@Awfulhak.org> said:
>
> > The rman stuff seems to be overkill:
>
> > o It uses a global mutex when allocating resources.
>
> ...which you can ignore...
>
> > o It has a local mutex for waiting on resources (and an RF_ACTIVE flag).
>
> ...which you can also ignore...
The way I see it, holding and releasing mutexes will introduce
contention between consumers that only want to maintain a [completely
private] sparce array.
> > o It supports RF_SHARABLE/RF_TIMESHARE resources (I guess this isn't
> > an overhead, just unnecessary).
>
> ...which you can also ignore...
Yes. It's just memory overhead.
> > o It's implemented in terms of ``struct resource *''s, most of which
> > inappropriate.
>
> Inappropriate in what way?
Allocating a ``struct resource'' munges a completely separate
resource (allocated units) in with all of the existing resources
providing contention, obfuscating the intent and providing all sorts
of lists and backwards pointers to achieve something that means
nothing in the context of these allocated units.
> > o It mucks about with device structs when reserving resources
>
> ...which you can just pass as a null pointer....
Unless DPRINTF is defined. But that could be fixed.
> > Do you really think it's appropriate to try to re-use the rman stuff
> > for what I want to do ?
>
> Given that the code is already there, and is already compiled into
> every kernel, and (I hope) already has the bugs worked out, I would
> suggest that it would not be a bad thing.
Hmmm, I would think that the memory and locking overheads outweigh
the code size overheads. The unit_list code is simple enough, so I
wouldn't think that the possibility of bugs would be a real problem.
> OTOH, if all you are doing is keeping an array of one-bit flags, and
> having an arbitrarily-large upper limit on the number of devices is
> acceptable, it's probably cheaper to just do it with a few macros.
I didn't do it that way because the ``usual'' way units are allocated
is sequentially. Using bits when there are large numbers of units
gets awkward. I figured what was required was something small and
simple that would cover the requirements of most/all drivers that
need to track their units so that it's easy to find an unused one,
and it's easy to allocate/deallocate things.
> -GAWollman
--
Brian <brian@Awfulhak.org> <brian@[uk.]FreeBSD.org>
<http://www.Awfulhak.org>; <brian@[uk.]OpenBSD.org>
Don't _EVER_ lose your sense of humour !
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?200105231552.f4NFqwF05688>