Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 19 Sep 2008 11:45:12 -0700
From:      Maxim Sobolev <sobomax@FreeBSD.org>
To:        Maksim Yevmenkin <maksim.yevmenkin@gmail.com>
Cc:        Ed Schouten <ed@80386.nl>, "current@freebsd.org" <current@FreeBSD.org>
Subject:   Re: Interface auto-cloning bug or feature?
Message-ID:  <48D3F338.1050505@FreeBSD.org>
In-Reply-To: <bb4a86c70809191140o4629159dl85af689bbce2c5a9@mail.gmail.com>
References:  <48D2F942.4070801@FreeBSD.org> <20080919101700.GS81522@hoeg.nl> <bb4a86c70809191140o4629159dl85af689bbce2c5a9@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Maksim Yevmenkin wrote:
> On 9/19/08, Ed Schouten <ed@80386.nl> wrote:
>> Hello Maxim,
>>
>>
>>  * Maxim Sobolev <sobomax@FreeBSD.org> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48D3F338.1050505>