From owner-freebsd-arch@FreeBSD.ORG Wed Jul 21 15:08:35 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 9CFCF16A4CE; Wed, 21 Jul 2004 15:08:35 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.12.11/8.12.11) with ESMTP id i6LF8ZND096616; Wed, 21 Jul 2004 11:08:35 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.12.11/8.12.11/Submit) id i6LF8YKK096615; Wed, 21 Jul 2004 11:08:34 -0400 (EDT) (envelope-from green) Date: Wed, 21 Jul 2004 11:08:33 -0400 From: Brian Fundakowski Feldman To: Poul-Henning Kamp Message-ID: <20040721150833.GG1009@green.homeunix.org> References: <1090412431.7114.13.camel@builder02.qubesoft.com> <83182.1090412961@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83182.1090412961@critter.freebsd.dk> User-Agent: Mutt/1.5.6i cc: arch@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: kldunload DIAGNOSTIC idea... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2004 15:08:36 -0000 On Wed, Jul 21, 2004 at 02:29:21PM +0200, Poul-Henning Kamp wrote: > In message <1090412431.7114.13.camel@builder02.qubesoft.com>, Doug Rabson write > s: > > >> The problem is that I cannot find the device_t without dereferencing > >> the struct cdev (either for si_driver[12] or the dev_t) and by then > >> it is too late. There is no way we can avoid refcounting on the cdev. > > > >Ok, so you are going to handle this in specfs (or whatever replaces > >specfs)? That makes sense. > > That's the only way I can see to avoid tons of copy&paste code all over > the drivers, because it's all the same for them. > > >Any ideas on how network interfaces should > >work in this? > > I talked with Robert briefly about this yesterday, and the problem > there is that struct ifnet is embedded in the softc. If the softc > had a pointer to the ifnet, then we could do something similar, but > as long as it's embedded we're stuck. What's the difference, when in the normal case (every case?) there is a poor-man's-OO implemented by making the softc's first member ifnet (or something containing ifnet like arpcom or ieee80211com), so a pointer to an ifnet or softc or whatever is almost always castable? I believe that this is a very traditional behavior. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\