Re: My planned work on networking stack (vimage)

From: Marko Zec (zec_at_tel.fer.hr)
Date: 03/02/04

  • Next message: Amar Takhar: "Re: if_bfe hangs?" 
    To: "James Read" <james@physicalsegment.com>, "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, <freebsd-net@freebsd.org>
Date: Tue, 2 Mar 2004 21:21:13 +0100

    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

    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

  • Next message: Amar Takhar: "Re: if_bfe hangs?"

    Relevant Pages

    • Re: Closing information leaks in jails?
      ... > restricted devfs in the jail (devfsrules_jail for example from ... but the primary IP address of the interfaces. ... > - some interesting information about the network related stuff via netstat ...
      (FreeBSD-Security)
    • Re: My planned work on networking stack (vimage)
      ... > this isnt exactly what jail was designed to do, ... > providing a clone-able network stack within jails. ... The fact that the virtualization patches are highly disruptive by their ... could have any future in the official FreeBSD tree... ...
      (freebsd-net)
    • Re: [Full-Disclosure] Disclose a bug, do not pass go, go directly to jail
      ... > company that was in the messaging business. ... its a blatent miscarrage to send someone to jail for this. ... The messages created a DoS for the company. ... takent he network down themseleves to fix the problem. ...
      (Full-Disclosure)
    • Re: lsm: add bsdjail documentation
      ... > Please use RFC private addresses in example code. ... Implements a subset of the BSD Jail functionality as a Linux LSM. ... May find it's valid network address under ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)