From owner-freebsd-net@FreeBSD.ORG Tue Jul 4 16:27:23 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CBB9A16A4DD; Tue, 4 Jul 2006 16:27:23 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22A6A43D68; Tue, 4 Jul 2006 16:27:23 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [IPv6:::1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k64GPaxe072159; Tue, 4 Jul 2006 10:25:36 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 04 Jul 2006 10:25:39 -0600 (MDT) Message-Id: <20060704.102539.-494099438.imp@bsdimp.com> To: brooks@one-eyed-alien.net From: "M. Warner Losh" In-Reply-To: <20060703202803.GA22556@odin.ac.hmc.edu> References: <44A40C25.904@elischer.org> <20060630115749.G3964@fledge.watson.org> <20060703202803.GA22556@odin.ac.hmc.edu> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: yar@comp.chem.msu.su, src-committers@freebsd.org, rwatson@freebsd.org, julian@elischer.org, freebsd-net@freebsd.org Subject: Re: cvs commit: src/sys/net if_vlan.c X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2006 16:27:23 -0000 In message: <20060703202803.GA22556@odin.ac.hmc.edu> Brooks Davis writes: : and act as though the interface is not there. We could then consider : either holding the interface for a configurable or computed length : of time or adding some sort of refcounting (probably impractical). Refcounting would be good for the 'macro' things (coming and going) that are infrequent, but we might have mulitple people doing. You are right it likely is too inefficient to do with mbugs. One other option might be to have a configurable time after the last time that it was accessed via the 'safe' routines that were setup. This way we'd tie the removal of the interface to a period of time after it was last used, rather than after it was removed. I don't know if such a difference would matter much in practice. The only other 'issue' that I see with this approach is if I remove a card, and then insert it again before the timeout happens. Does that card get a new interface name? And would people care or not... Warner