Date: Wed, 23 May 2001 22:09:27 +0100 From: Brian Somers <brian@Awfulhak.org> To: Brian Somers <brian@Awfulhak.org> Cc: Mike Smith <msmith@FreeBSD.ORG>, freebsd-arch@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: RFC: unit_list routines Message-ID: <200105232109.f4NL9RF11365@hak.lan.Awfulhak.org> In-Reply-To: Message from Brian Somers <brian@Awfulhak.org> of "Wed, 23 May 2001 21:20:02 BST." <200105232020.f4NKK2F10389@hak.lan.Awfulhak.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > > >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
--
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?200105232109.f4NL9RF11365>