Date: Wed, 21 Jul 2004 11:08:33 -0400 From: Brian Fundakowski Feldman <green@freebsd.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: freebsd-arch@freebsd.org Subject: Re: kldunload DIAGNOSTIC idea... Message-ID: <20040721150833.GG1009@green.homeunix.org> In-Reply-To: <83182.1090412961@critter.freebsd.dk> References: <1090412431.7114.13.camel@builder02.qubesoft.com> <83182.1090412961@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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. \,,,,,,,,,,,,,,,,,,,,,,\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040721150833.GG1009>