Date: Tue, 2 Mar 2004 21:21:13 +0100 From: Marko Zec <zec@tel.fer.hr> To: "James Read" <james@physicalsegment.com>, "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, <freebsd-net@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: My planned work on networking stack (vimage) Message-ID: <200403022121.15400.zec@tel.fer.hr> In-Reply-To: <00d301c40089$8a035410$c000000a@jd2400> References: <4043B6BA.B847F081@freebsd.org> <Pine.BSF.4.53.0403021802320.78288@e0-0.zab2.int.zabbadoz.net> <00d301c40089$8a035410$c000000a@jd2400>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200403022121.15400.zec>