Date: Wed, 5 Jul 2000 10:00:29 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Archie Cobbs <archie@whistle.com> Cc: "Andrey A. Chernov" <ache@FreeBSD.ORG>, freebsd-net@FreeBSD.ORG Subject: Re: cvs commit: src/sys/net if.c if_ethersubr.c if_var.h Message-ID: <Pine.NEB.3.96L.1000705095331.27818B-100000@fledge.watson.org> In-Reply-To: <200007011627.JAA05559@bubba.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
(I've redirected this to freebsd-net, but Bcc'd committers and cvs-all since that is where it started) On Sat, 1 Jul 2000, Archie Cobbs wrote: > I'm going to fix that later. Right now you'll get a panic if you > eject a PCCARD ethernet that was doing netgraph, unfortunately. > > The problem is that the interfaces are not very object oriented > (with respect to type), combined with the dynamically loadable code. > As an example of the former, all ethernet drivers call if_attach() > and ether_attach() when connecting, but only if_detach() when > disconnecting. Perhaps they should all only call ether_attach() > and ether_detach(). > > The simplest 'correct' solution I can think of is to have a linker set > into which each interface type could link if it wanted to have a > special if_detach() callout.. and then put ethernet in there, so > it can call (*ng_ether_detach_p)() when an ethernet interface is > detached. > > Got any better ideas? > > Anyway, I'm on vacationthis next week so probably won't get around > to fixing this until after then.. unless someone else wants to > take a stab. This is similar to the bpf_detach() issue a few months ago -- nested, typed attaches and detaches might be beter handled in a more OOP way -- perhaps if_detach() should take the DLT type, allowing it to determine the appropriate set of attaches based on that type, which would include bpf_attach/detach, ether_attach/detach, ng attaching, and so on. BTW, one of the current causes of panics associated with removable ethernet devices is the (struct ifnet *) pointer in mbuf's. We use the pointer for a number of things, including ipfw rules with interface entries, bpf "seen" detection for packets, et al. However, when the struct ifnet is freed, needless to say, the results are unfortunate. A number of people have chatted about this at various times, and potential solutions include garbage collecting (the solution for BPF attachments in bpf_detach, but scales poorly to mbufs), an extra level of indirection (which would leak a (struct ifnet *) but allow NULLing of the pointer without tracking down all entries), and just leaking the struct ifnet. In a world of virtual interfaces and netgraph (a world a promote), I think we need to solve the removable interface issue properly. Refcounting is probably too heavy weight for mbuf creation/deletion, as it would require a lock for the struct ifnet during mbuf handling, which would be nasty. It could be worked around by storing queues of extra mbufs off the ifnet, or storing a symbolic name for the ifnet (since it is infrequently used) and doing a lookup when necessary. Anyhow, your thoughts (and even solutions here) are welcome :-). Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1000705095331.27818B-100000>