kldunload DIAGNOSTIC idea...

Brian Fundakowski Feldman green at freebsd.org
Wed Jul 21 08:08:36 PDT 2004


On Wed, Jul 21, 2004 at 02:29:21PM +0200, Poul-Henning Kamp wrote:
> In message <1090412431.7114.13.camel at 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 at FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\


More information about the freebsd-arch mailing list