Date: Fri, 16 Sep 2005 15:13:01 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: ru@FreeBSD.org Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org, jhb@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/re if_re.c Message-ID: <20050916.151301.122028383.imp@bsdimp.com> In-Reply-To: <20050916202207.GA22151@ip.net.ua> References: <20050916194405.GB24879@ip.net.ua> <20050916.135841.130619528.imp@bsdimp.com> <20050916202207.GA22151@ip.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20050916202207.GA22151@ip.net.ua>
Ruslan Ermilov <ru@FreeBSD.org> writes:
: Hmm, I'm not very fluent in device(9) API, but I wonder what's then
: the analog of device_delete_child(sc->miibus) that the majority of
: foo_detach() methods do. I.e., will the miibus device really be
: removed?
Yes. I believe so.
: > How again can this happen?
: >
: tcpdump -n -i ed0 &
: kldunload if_ed
:
: Still, ed_init_locked() will instantiate many things inappropriate
: for ed_detach() context.
How does ed_init_locked get called in ed_detach()? It looks to me
that ed_stop is called, but ed_init() isn't. Where would it be
called?
: When experimenting with removing device_delete_child(sc->miibus)
: in rl(4), every new kldunload/kldload will add another miibusX
: device, showing that the child device removal doesn't happen
: implicitly. I wonder if you can see the same with ed(4), or
: if there's some code that does this. Also, the code that you
: refer seems to only work for pccard, while PCI version should
: be affected by the same "mii == NULL" bug.
There's no ed + mii + pci. I'll take a look at these details
tonight.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050916.151301.122028383.imp>