24 messages in org.freebsd.freebsd-archkldunload DIAGNOSTIC idea...| From | Sent On | Attachments |
|---|---|---|
| Poul-Henning Kamp | Jul 20, 2004 11:21 am | |
| Brian Fundakowski Feldman | Jul 20, 2004 11:32 am | |
| Poul-Henning Kamp | Jul 20, 2004 11:40 am | |
| Brian Fundakowski Feldman | Jul 20, 2004 11:53 am | |
| Willem Jan Withagen | Jul 20, 2004 12:08 pm | |
| Scott Long | Jul 20, 2004 12:09 pm | |
| Scott Long | Jul 20, 2004 12:11 pm | |
| David Schultz | Jul 20, 2004 1:40 pm | |
| Andrea Campi | Jul 20, 2004 11:18 pm | |
| Poul-Henning Kamp | Jul 20, 2004 11:47 pm | |
| Julian Elischer | Jul 21, 2004 12:09 am | |
| Doug Rabson | Jul 21, 2004 2:10 am | |
| Poul-Henning Kamp | Jul 21, 2004 2:22 am | |
| Doug Rabson | Jul 21, 2004 3:37 am | |
| Poul-Henning Kamp | Jul 21, 2004 4:02 am | |
| Doug Rabson | Jul 21, 2004 4:20 am | |
| Poul-Henning Kamp | Jul 21, 2004 4:37 am | |
| Doug Rabson | Jul 21, 2004 5:20 am | |
| Poul-Henning Kamp | Jul 21, 2004 5:30 am | |
| M. Warner Losh | Jul 21, 2004 7:51 am | |
| Brian Fundakowski Feldman | Jul 21, 2004 8:08 am | |
| Poul-Henning Kamp | Jul 21, 2004 9:38 am | |
| M. Warner Losh | Jul 21, 2004 10:14 am | |
| Poul-Henning Kamp | Jul 21, 2004 10:16 am |
| Subject: | kldunload DIAGNOSTIC idea... | |
|---|---|---|
| From: | Brian Fundakowski Feldman (gre...@freebsd.org) | |
| Date: | Jul 21, 2004 8:08:28 am | |
| List: | org.freebsd.freebsd-arch | |
On Wed, Jul 21, 2004 at 02:29:21PM +0200, Poul-Henning Kamp wrote:
In message <1090...@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 ]''''''''''\ <> gre...@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\