Date: Wed, 23 May 2001 09:15:41 +0100 From: Brian Somers <brian@Awfulhak.org> To: Peter Wemm <peter@wemm.org> Cc: Brian Somers <brian@Awfulhak.org>, Poul-Henning Kamp <phk@critter.freebsd.dk>, Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, freebsd-arch@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: RFC: unit_list routines Message-ID: <200105230815.f4N8FfC20001@hak.lan.Awfulhak.org> In-Reply-To: Message from Peter Wemm <peter@wemm.org> of "Tue, 22 May 2001 19:23:29 PDT." <20010523022329.ADF97380A@overcee.netplex.com.au>
index | next in thread | previous in thread | raw e-mail
> > The unit_list is an ordered list of ranges where the count is
> > implicit and a resource id or type field have no meaning. The idea
> > is to be able to allocate and release unit numbers relatively
> > frequently without obfuscating things with redundant information or
> > including odd things such bus hierarchies and unit counts.
>
> That is exactly what the rman stuff is for.
The rman stuff seems to be overkill:
o It uses a global mutex when allocating resources.
o It has a local mutex for waiting on resources (and an RF_ACTIVE flag).
o It supports RF_SHARABLE/RF_TIMESHARE resources (I guess this isn't
an overhead, just unnecessary).
o It's implemented in terms of ``struct resource *''s, most of which
inappropriate.
o It mucks about with device structs when reserving resources
unit_list just concerns itself with allocating a bunch of int ranges.
Do you really think it's appropriate to try to re-use the rman stuff
for what I want to do ?
> Cheers,
> -Peter
> --
> Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
> "All of this is for nothing if we don't go to the stars" - JMS/B5
--
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
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200105230815.f4N8FfC20001>