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 >Received on Fri Sep 19 2008 - 17:24:13 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:35 UTC