Date: Wed, 23 May 2001 23:12:34 -0700 From: Peter Wemm <peter@wemm.org> To: Brian Somers <brian@Awfulhak.org> Cc: Mike Smith <msmith@FreeBSD.ORG>, freebsd-arch@FreeBSD.ORG Subject: Re: RFC: unit_list routines Message-ID: <20010524061235.0413C380C@overcee.netplex.com.au> In-Reply-To: <200105232109.f4NL9RF11365@hak.lan.Awfulhak.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Brian Somers wrote:
> > > > > > >I didn't do it that way because the ``usual'' way units are alloca
ted
> > > > > > >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 bu
s */
> > > > 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.
Uhh... what crack are you smoking? devclasses are not invloved here.
if_tun does not use *any* newbus code or interfaces. subr_bus.c is not
involved.
peter@overcee[11:06pm]~src/sys/net-118> grep bus.h if_tun*
peter@overcee[11:07pm]~src/sys/net-119>
> 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
Exactly. rman will deal with this just fine. The network stack may not,
since it uses indexes etc, but rman wont have the slightest problem.
Suppose you have tun0, tun1 and tun16777215.. That is something like 4
struct rman nodes. (one for tun0, one for tun1, one placeholder
for the sparse range between tun2 and tun16777214, and one for tun16777215)
Besides, the sys/kern/unit_list.c and sys/unit_list.h files are badly
misnamed. At the very least, it should be sys/kern/subr_units.c or
something along those lines. (next to subr_bus.c and subr_rman.c).
I still dont believe that we need it though.
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
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?20010524061235.0413C380C>