From owner-freebsd-arch Thu May 24 3: 9:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by hub.freebsd.org (Postfix) with ESMTP id 5CC1937B422; Thu, 24 May 2001 03:09:54 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-31.mail.demon.net with esmtp (Exim 2.12 #1) id 152s41-000Iwo-0V; Thu, 24 May 2001 11:09:53 +0100 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f4OA8b758888; Thu, 24 May 2001 11:08:37 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Thu, 24 May 2001 11:08:37 +0100 (BST) From: Doug Rabson To: Brian Somers Cc: Mike Smith , Subject: Re: RFC: unit_list routines In-Reply-To: <200105232109.f4NL9RF11365@hak.lan.Awfulhak.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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