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>