Re: Interface auto-cloning bug or feature?

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).

thanks,
max