My planned work on networking stack (vimage)

[Marko Zec]

On Tuesday 02 March 2004 20:06, James Read wrote:
> > I still have in mind that I would like to see vimage[1] in HEAD one
> > day ... I think it would be a pretty cool feature to have. If one
> > can keep this in mind when doing greater modelling on the network
> > stack it might help the one who will - at some time - find the time
> > to ingtegrate it.
> >
> >
> > [1] http://www.tel.fer.hr/zec/BSD/vimage/index.html
>
> </Off Topic>
>
> In my opinion, this would be a _VERY_ good 'feature' to add into the
> system. As it stands there is minimal 'networking' in a jail from a
> users point of view, and also an administrators view aswell (granted
> this isnt exactly what jail was designed to do, and so on). This
> could be more then an asset to the whole jail architecture, by
> providing a clone-able network stack within jails. For instance, you
> could then run programs/services like NFS etc from jail to jail
> without having to lock down services offered from the jail 'host'.
>
> If this can in _any way_ be pushed/implemented (with minimal
> distruption) so that is it in HEAD/CURRENT then its well on the way
> to complementing what 'jail' does.

The fact that the virtualization patches are highly disruptive by their 
nature seem to me as the #1 reason they might never become suitable for 
inclusion in the main tree. Namely, the basic idea is to replace (most 
of) the global symbols/variables throughout the entire network stack 
with their counterparts residing in "clonable" structures or resource 
containers. While such a concept doesn't introduce any real-life 
performance penalty worth mentioning, the real issue is that the 
compatibility / synchronization with any parallel or external code 
would be unavoidably lost once the patchset would be committed. However 
I might be wrong...

It would be nice if a wider discussion could try to weight out all pros 
and cons and yield a consensus whether or not any vimage-style patches 
could have any future in the official FreeBSD tree...

Cheers,

Marko