Interface auto-cloning bug or feature?
Maksim Yevmenkin
maksim.yevmenkin at gmail.com
Fri Sep 19 19:24:13 UTC 2008
On 9/19/08, Maxim Sobolev <sobomax at freebsd.org> wrote:
> Maksim Yevmenkin wrote:
>
> > On 9/19/08, Ed Schouten <ed at 80386.nl> wrote:
> >
> > > Hello Maxim,
> > >
> > >
> > > * Maxim Sobolev <sobomax at 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
>
More information about the freebsd-current
mailing list