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, MarkoReceived on Tue Mar 02 2004 - 11:22:03 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:45 UTC