Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 May 2009 14:50:48 -0700
From:      Julian Elischer <julian@elischer.org>
To:        Marko Zec <zec@FreeBSD.org>
Cc:        virtualization@freebsd.org, Perforce Change Reviews <perforce@freebsd.org>
Subject:   Re: PERFORCE change 161987 for review
Message-ID:  <4A09EF38.6060407@elischer.org>
In-Reply-To: <200905121848.n4CImKQt036691@repoman.freebsd.org>
References:  <200905121848.n4CImKQt036691@repoman.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Marko Zec wrote:
> http://perforce.freebsd.org/chv.cgi?CH=161987
> 
> Change 161987 by zec@zec_tpx32 on 2009/05/12 18:47:49
> 
> 	Back out O(n**2) ad-hoc hack for searching for available
> 	ifunits in cloning ifnets, and restore the standard O(n)
> 	bitmapped searching / ifunit allocation method for both
> 	default and options VIMAGE builds.
> 	
> 	HOWEVER, hereby we also introduce per-vnet if_clone driver
> 	registration and ifunit allocation.  As a (necessary) example,
> 	if_loop is modified to attach itself as an independent
> 	cloner instance to each vnet.
> 	
> 	This approach has a neat byproduct: if_clone drivers that
> 	do not explicitly declare themselves as multi-vnet, by
> 	exporting an iattach() method and registering to the vnet
> 	framework, continue to work with unmodified semantics in
> 	the default vnet.  However, they will NOT be available
> 	in other vnets.

Ah I didn't read this right the first time..
generally, good but...

So we cannot have tun drivers in vimages?

tun needs it's /dev  entres, so can not be 'renumbered' (in the
base sense) until we somehow add vimage support to devfs.
however having tun3 in one vimage and tun4 in another would still
be pretty ok I think. So I think the modes wanted would be:

"Unvirtualised"    appears in base vimage only
"Scattered"        one namespace, but in different vimages.
"Virtualised"      separate namespaces.

p.s excuse my unamerican way of spelling 'ised' (not ized)
my fingers refuse to co-operate.

> 	
> 	This brings us a step closer to being able to selectively
> 	attach subsystems to particular vnets, instead of having
> 	all subsystems unconditionally available to all vnets by
> 	default.
> 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A09EF38.6060407>