Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 24 May 2001 11:08:37 +0100 (BST)
From:      Doug Rabson <dfr@nlsystems.com>
To:        Brian Somers <brian@Awfulhak.org>
Cc:        Mike Smith <msmith@FreeBSD.ORG>, <freebsd-arch@FreeBSD.ORG>
Subject:   Re: RFC: unit_list routines 
Message-ID:  <Pine.BSF.4.33.0105241107040.58788-100000@herring.nlsystems.com>
In-Reply-To: <200105232109.f4NL9RF11365@hak.lan.Awfulhak.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 23 May 2001, Brian Somers wrote:

> > > > > > >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.
> > > > > >
> > > > > > How does newbus allocate/manage unit numbers ?
> > > > >
> > > > > I don't think it does.  The only way to find out what's in use
> > > > > (AFAIK) is by looking at every specinfo in dev_hash....
> > > >
> > > > Er, what exactly are you smoking?
> > > >
> > > > Newbus manages unit numbers using the devclass:
> > > >
> > > > struct devclass {
> > > >     TAILQ_ENTRY(devclass) link;
> > > >     driver_list_t       drivers; /* bus devclasses store drivers for bus */
> > > >     char                *name;
> > > >     device_t            *devices; /* array of devices indexed by unit */
> > > >     int                 maxunit; /* size of devices array */
> > > > };
> > >
> > > Yes, Garrett pointed this out.  I misunderstood the question because
> > > newbus doesn't manage unit numbers.  It ``manages'' the maximum unit
> > > number allocated and nothing else.
> > >
> > > My answer was describing the only way I know of to figure out which
> > > units for a given device are allocated/opened.
> >
> > Hmm, hang on.  I'll stop smoking....  If that device_t array knows
> > which devices are open it could solve my problems...
>
> Where did I put that smoke....
>
> Anyone care to try
>
> # ppp -unit 16777215
>
> I don't care for the consistency of the results (/dev/tun16777215 is
> created ok, but seems to be talking to interface tun0).  Is subr_bus.c
> *really* trying to allocate 0xffffff device_t pointers and set them
> all except the last to NULL ?  That's 67Mb of memory.
>
> Funnily enough, netstat -i takes quite a while to run, and yep, I'm
> using up a bit of swap.
>
> I think devclass needs to be fixed.  Maybe it should use this new
> ``struct unit_list'' that I happen to have handy - or even better, it
> could use the rman stuff !!! :*D

It might be worthwhile to make devclass use rman. Fortunately for driver
writers, this part of the implementation is entireley hidden and changing
it would be trivial and wouldn't affect existing drivers (source *or*
binary).

-- 
Doug Rabson				Mail:  dfr@nlsystems.com
					Phone: +44 20 8348 6160



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?Pine.BSF.4.33.0105241107040.58788-100000>