From owner-freebsd-hackers Tue Jun 12 12: 7:56 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from peace.mahoroba.org (peace.calm.imasy.or.jp [202.227.26.34]) by hub.freebsd.org (Postfix) with ESMTP id AFA3537B405; Tue, 12 Jun 2001 12:07:39 -0700 (PDT) (envelope-from ume@mahoroba.org) Received: from localhost (IDENT:pEJFMaVQrDHE+c3cetChVyrKhLrBCZZZhBr2ajjhCSD4ohFgKyS/C98p/nLxaVXp@localhost [::1]) (authenticated as ume with CRAM-MD5) by peace.mahoroba.org (8.11.4/8.11.4/peace) with ESMTP/inet6 id f5CJ7Gq66978; Wed, 13 Jun 2001 04:07:16 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Wed, 13 Jun 2001 04:07:16 +0900 (JST) Message-Id: <20010613.040716.115941864.ume@mahoroba.org> To: brooks@one-eyed-alien.net Cc: hackers@FreeBSD.ORG, brian@Awfulhak.org, phk@critter.freebsd.dk, arch@FreeBSD.ORG Subject: Re: cloning network interfaces From: Hajimu UMEMOTO In-Reply-To: <20010611142030.A15283@Odin.AC.HMC.Edu> References: <20010608191904.A18847@Odin.AC.HMC.Edu> <20010610.232907.74740159.ume@mahoroba.org> <20010611142030.A15283@Odin.AC.HMC.Edu> X-Mailer: xcite1.38> Mew version 1.95b119 on Emacs 20.7 / Mule 4.0 =?iso-2022-jp?B?KBskQjJWMWMbKEIp?= X-PGP-Public-Key: http://www.imasy.org/~ume/publickey.asc X-PGP-Fingerprint: 6B 0C 53 FC 5D D0 37 91 05 D0 B3 EF 36 9B 6A BC X-URL: http://www.imasy.org/~ume/ X-Operating-System: FreeBSD 5.0-CURRENT Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >>>>> On Mon, 11 Jun 2001 14:20:31 -0700 >>>>> Brooks Davis said: brooks> On Sun, Jun 10, 2001 at 11:29:07PM +0900, Hajimu UMEMOTO wrote: > I think it is not BSD network way. Recent NetBSD has network > interface cloning. It uses SIOCIFCREATE and SIOCIFDESTROY. It may > good to port it to FreeBSD. brooks> I've looked it over and I generally like it. There is one problem brooks> though. That's the requirement that you use static units. The problem brooks> with this is that it forces you to implement free unit scanning in brooks> userland if you just want to create a unit and don't care what it is. brooks> If you have to do this, and things are being changed at any kind of brooks> significant rate, you have race condition between scanning the brooks> interface list for a free unit and trying to allocate it. This race can brooks> theoreticaly lead to starvation. I see. brooks> My proposed solution is threefold. First, change the ifc_create pointer's brooks> type to: brooks> int (*ifc_create)(struct if_clone *, int *); brooks> so you can return a unit if the caller requests a wildcard unit (by brooks> passing -1). Second, move unit management in to the driver rather then brooks> just using ifunit in if_clone_create. Drivers could choose to implement brooks> wildcarding or not and if not could simply use ifunit for their test. brooks> Third, make if_clone_lookup treat names like "gif#" as a wildcard brooks> request and set unit to -1 as appropriate. These changes break brooks> compatability with NetBSD slightly, but it's just a few lines to convert brooks> an existing NetBSD clone_create handler to this style and it could brooks> easily be handled with #ifdef's. brooks> Thoughts, comments, objections? I like your idea. I'm serving tunnel broker using DTCP (Dynamic Tunnel Configuration Protocol) in our ISP. So, I'm grad if we have dynamic gif creation, too. -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message