On Tuesday 12 May 2009 23:50:48 Julian Elischer wrote:
> Marko Zec wrote:
> > http://perforce.freebsd.org/chv.cgi?CH=161987
> >
> > Change 161987 by z...@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.
Hmm but how would such an approach help with say /dev/pf, which also has to be
functional in all vnets? Wouldn't it be useful if a single /dev entry could
provide access to appropriate subsystem instances in different vnets,
depending in which vnet the process which opens the special file operates?
I think this is how the virtualized pf did work, and there's anegdotal
evidence that it did work well, at least until this got ripped off the vimage
branch with the next pf import from OpenBSD :)
Marko
> 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.
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
"freebsd-virtualization-unsubscr...@freebsd.org"
