Re: kldunload DIAGNOSTIC idea...
From: Brian Fundakowski Feldman (green_at_freebsd.org)
Date: 07/21/04
- Previous message: M. Warner Losh: "Re: kldunload DIAGNOSTIC idea..."
- In reply to: Poul-Henning Kamp: "Re: kldunload DIAGNOSTIC idea..."
- Next in thread: Brian Fundakowski Feldman: "Re: kldunload DIAGNOSTIC idea..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 21 Jul 2004 11:08:33 -0400 To: Poul-Henning Kamp <phk@phk.freebsd.dk>
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. \,,,,,,,,,,,,,,,,,,,,,,\ _______________________________________________ freebsd-arch@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
- Previous message: M. Warner Losh: "Re: kldunload DIAGNOSTIC idea..."
- In reply to: Poul-Henning Kamp: "Re: kldunload DIAGNOSTIC idea..."
- Next in thread: Brian Fundakowski Feldman: "Re: kldunload DIAGNOSTIC idea..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
