Date: Fri, 19 Sep 2008 12:24:12 -0700 From: "Maksim Yevmenkin" <maksim.yevmenkin@gmail.com> To: "Maxim Sobolev" <sobomax@freebsd.org> Cc: Ed Schouten <ed@80386.nl>, "current@freebsd.org" <current@freebsd.org> Subject: Re: Interface auto-cloning bug or feature? Message-ID: <bb4a86c70809191224g2d1f7a4bo2ef1e10b9c3c843c@mail.gmail.com> In-Reply-To: <48D3F338.1050505@FreeBSD.org> References: <48D2F942.4070801@FreeBSD.org> <20080919101700.GS81522@hoeg.nl> <bb4a86c70809191140o4629159dl85af689bbce2c5a9@mail.gmail.com> <48D3F338.1050505@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9/19/08, Maxim Sobolev <sobomax@freebsd.org> wrote: > 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. why indeed :) i'll try to hack something up in the next couple of hours or so. stay tuned. thanks, max > > -Maxim >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bb4a86c70809191224g2d1f7a4bo2ef1e10b9c3c843c>