From owner-freebsd-arch@FreeBSD.ORG Wed Jul 21 17:12:21 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C9C9816A4CE for ; Wed, 21 Jul 2004 17:12:21 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 569A143D39 for ; Wed, 21 Jul 2004 17:12:21 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i6LHAgX7061719; Wed, 21 Jul 2004 11:10:43 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 21 Jul 2004 11:10:45 -0600 (MDT) Message-Id: <20040721.111045.88466992.imp@bsdimp.com> To: phk@phk.freebsd.dk From: "M. Warner Losh" In-Reply-To: <84655.1090427927@critter.freebsd.dk> References: <20040721.084926.84362543.imp@bsdimp.com> <84655.1090427927@critter.freebsd.dk> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@FreeBSD.org Subject: Re: kldunload DIAGNOSTIC idea... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2004 17:12:21 -0000 In message: <84655.1090427927@critter.freebsd.dk> "Poul-Henning Kamp" writes: : In message <20040721.084926.84362543.imp@bsdimp.com>, "M. Warner Losh" writes: : >[[ only cc'd arch@ ]] : > : >In message: <83182.1090412961@critter.freebsd.dk> : > "Poul-Henning Kamp" writes: : >: >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. : > : >Why is that the case? We don't detach the ifnet stuff after deleting : >the softc. Why would a pointer to ifnet in the softc make this : >easier? : : Because it would allow the softc could be freed before the ifnet : structure. But the ifnet structure has a back pointer to the softc. What would this accomplish? struct ifnet { void *if_softc; /* pointer to driver state */ so you'd have to zero this out, and then change all the places that dereference this to check for NULL. :-( : >I mean, I understand that having a pointer would insulate the size of : >ifnet from the driver, but there's so many offsets in ifnet that are : >encoded in the driver that doesn't seem that big a win. : : That's not the point here. The problem here is that we cannot unload : the driver until we have hunted down and exterminated all references : to the ifnet structure. We can't unload the driver until we've exterminated all references to softc too. : If softc only pointed to the ifnet, we could neuter the ifnet (like : we do for cdev and vnodes with a set of dead_* functions) wait for : all threads to drain out of the module and unload it. The ifnet : cleanup will happen "when convenient". We still ahve to wait for all threads with references to softc to drain out before we unload the module. I see a small benefit to that, but it seems that the requirements for softc are stronger than ifnet and already cover it. The detach routine of the driver could easily wait for the ifnet reference count to drop before returning for network drivers (heck the if_detach call could wait all references are gone, so that it isn't actually in the driver). Where it is stored seems not to matter so much. Warner