From owner-freebsd-current@FreeBSD.ORG Fri Sep 19 18:45:36 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 7C2D11065673 for ; Fri, 19 Sep 2008 18:45:36 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 2E8838FC23 for ; Fri, 19 Sep 2008 18:45:36 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.61] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id m8JIjAnC075290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Sep 2008 11:45:15 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <48D3F338.1050505@FreeBSD.org> Date: Fri, 19 Sep 2008 11:45:12 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Maksim Yevmenkin References: <48D2F942.4070801@FreeBSD.org> <20080919101700.GS81522@hoeg.nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 18:45:36 -0000 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. -Maxim