From owner-freebsd-arch Tue Dec 14 15:40: 5 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 91F29154F4 for ; Tue, 14 Dec 1999 15:39:58 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA10017 for ; Wed, 15 Dec 1999 00:39:48 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA66848 for freebsd-arch@freebsd.org; Wed, 15 Dec 1999 00:39:47 +0100 (MET) Received: from sumatra.americantv.com (sumatra.americantv.com [208.139.222.227]) by hub.freebsd.org (Postfix) with ESMTP id E9A38151F9 for ; Tue, 14 Dec 1999 15:39:38 -0800 (PST) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id RAA23303; Tue, 14 Dec 1999 17:39:38 -0600 (CST) Received: (from jlemon@localhost) by right.PCS (8.8.5/8.6.4) id RAA17334; Tue, 14 Dec 1999 17:39:36 -0600 (CST) Message-ID: <19991214173936.37821@right.PCS> Date: Tue, 14 Dec 1999 17:39:36 -0600 From: Jonathan Lemon To: Brian Somers Cc: arch@freebsd.org Subject: Re: The if_detach problem References: <199912142322.XAA36949@hak.lan.Awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 In-Reply-To: <199912142322.XAA36949@hak.lan.Awfulhak.org>; from Brian Somers on Dec 12, 1999 at 11:22:15PM +0000 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Dec 12, 1999 at 11:22:15PM +0000, Brian Somers wrote: > > On Dec 12, 1999 at 09:45:36PM +0000, Brian Somers wrote: > > > > > > > > if_detach doesn't, at least not completely. > > > > > > > > That's a problem when you want to remove interfaces. One problem is > > > > that the routing system caches ifaddr and other things. There is a > > > > mechanism in place that could be used to clean things up. > > > > > > > > In the protosw there is a ctlinput routine which accepts various > > > > commands. One way to deal with this is to send a new command when ifa > > > > goes away. Right now when we do if_down we send a PRC_IFDOWN. Maybe > > > > we need to invent a new PRC_, say PRC_IFDETACH. Then we wouldn't need > > > > the kludges in if_detach. The ctlinput routines could then, in the > > > > appropriate places, scrub the references to the interface that just > > > > went away. > > > > > > > > I'd like to go down this path, any comments? > > > > > > Not comments, but my thoughts.... > > > > > > Is there a lot to be gained by removing interfaces ? > > > > Loadable device drivers. I ran into this last week or so when > > unloading a driver I'm developing; if I don't do an 'ifconfig xxx delete' > > before the kldunoad, I get a panic. > > Right, but how about a ``notthere'' flag instead ? > > My concern is that there are some APIs that use interface ids > (sysctl(PF_ROUTE) springs to mind) and some APIs that use > interface names (the struct ifaliasreq ioctls etc) and reassigning > the association between the two on the fly seems a tad dangerous - > lots of races. I'd think that trying to maintain a 'notthere' pseudo-state would lead to more problems in the kernel that just doing splhigh() for a short time to remove/rewrite the associations. > Another (more real?) argument for keeping the interface but making it > unusable 'till the driver wants it again is that there may be > security concerns.... at the moment, ``netstat -i'' reports what's > been going on very nicely. Removing the interface entirely will > allow people to hide what should not be hidden.... I'm not sure this applies. At the moment, `netstat -i' does not show interfaces which have no driver in the system. So if I load and then _unload_ a driver, what should 'netstat -i' report? The name of the (nonexistent) driver? Similarly, if the hardware happens to be a PCCARD, and it's popped out, its gone, and there isn't any point in keeping the iface around forever. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message