From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 19:24:13 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62290106566C for ; Fri, 19 Sep 2008 19:24:13 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by mx1.freebsd.org (Postfix) with ESMTP id 358A88FC14 for ; Fri, 19 Sep 2008 19:24:13 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so505092rvf.43 for ; Fri, 19 Sep 2008 12:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=szG2FJ+LX8/4e6DgH8jl94r8b/B0K5QsMRnlKid+rWg=; b=YQpt/LLxMC3fJrP/fZIVgXKfvECApNqeL7PAImrSnS/eViDiIwM5b2gyN7U9D50uBF yn5JvJ/KNcyBwwue88JLiQIr5Hoxt2tCXSyStq6/rFZrrvh3yEDbGOOvnymtTjjsQj18 izG7GHGmd4GPktJoBdw8ghJz5TB6yPV92euJo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=G6u2sPfNDGwFTlpRBgKwBCVw56bpvZ0emGv0C4FcOpsePRH4IwdMzNKImnnmUIKjwY qjU2KPjw8tepK+Ic4bo6MzA2uhoDVbKY3MYH58NSbgokEcNAqwMiEen8+xzEhQNZCr94 e1O6dRDuNMPyDkd4qa9eFcbApFxi3E8fuDZFE= Received: by 10.140.127.20 with SMTP id z20mr287199rvc.77.1221852253002; Fri, 19 Sep 2008 12:24:13 -0700 (PDT) Received: by 10.141.197.13 with HTTP; Fri, 19 Sep 2008 12:24:12 -0700 (PDT) Message-ID: Date: Fri, 19 Sep 2008 12:24:12 -0700 From: "Maksim Yevmenkin" To: "Maxim Sobolev" In-Reply-To: <48D3F338.1050505@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48D2F942.4070801@FreeBSD.org> <20080919101700.GS81522@hoeg.nl> <48D3F338.1050505@FreeBSD.org> Cc: Ed Schouten , "current@freebsd.org" Subject: Re: Interface auto-cloning bug or feature? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2008 19:24:13 -0000 On 9/19/08, Maxim Sobolev wrote: > Maksim Yevmenkin wrote: > > > On 9/19/08, Ed Schouten wrote: > > > > > Hello Maxim, > > > > > > > > > * Maxim Sobolev wrote: > > > > I've noticed that stat/open call on /dev/tun always creates new > > > > interface, despite the fact that existing spare interfaces may be > > > > available. I believe that it's a bug, since the whole purpose of > > > > auto-cloning is to create new instance only when no existing one > could > > > > be allocated. At least that's my reading of the manual page for the > tun(4). > > > > > > > > > I'd say the best way to fix this would be to convert tun and tap to > > > devfs_[gs]et_cdevpriv() and turn tun and tap into single device nodes. > > > That's what we've already been doing to bpf, snp, audit_pipe, etc. > > > Unfortunately I'm no expert when it comes to our tun and tap > > > implementations. > > > > > > > not so fast please :) the tap/tun/vkbd (and maybe others) have split > > personality. that is, on one side there is a network interface or > > keyboard, and on the other side is character device. those are always > > go in pairs. as far as i understand, of > > dev_stdclone/clone_create/clonedevs list/etc. is here to > free up > > driver from managing resources (such as minor numbers). sure we can > > convert those drivers to devfs_set/get_cdevpriv, however, split > > personality drivers will still have to manage something similar to > > minor numbers (to name network interfaces/keyboards associated with > > the particular cdevpriv instance). also we need to make sure that any > > code still could use /dev/tunX/tapX names and get correct tunX/tapX > > interface (provided, of course, one is available). > > > > Why opening /dev/tun can't search and return the first unopened instance > (as the manpage suggests it would) instead of unconditionally allocating a > new one? Seems to me like a trivial change, most of the code is already > there. why indeed :) i'll try to hack something up in the next couple of hours or so. stay tuned. thanks, max > > -Maxim >