[lkml]   [2006]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] [PATCH 0/7] Some basic vserver infrastructure
    Dave Hansen wrote:

    >That said, at this point, I'd just about rather have _anything_ merged
    >than the nothing we have at this point. As we throw patches back and
    >forth, we can't seem to agree on even some very small points.
    >I also have a sinking feeling that everybody has gone back off and
    >continues to develop their own out-of-tree functionality, deepening the
    >patch divide.
    >Is there anything we could merge that we _all_ don't like? I'm pretty
    >convinced that no single solution will support Eric's, OpenVZ's, and
    >VServer's _existing_ usage models. Somebody is going to have to bend,
    >or nothing will ever get merged. Any volunteers? ;)

    I don't think they're all that different conceptually. If something as
    simple as this was merged then we'd at least have a common structure to
    throw things in, and a common syscall infrastructure that can gracefully
    handle kernel API versioning without requiring dozens of syscalls.

    >What about going back to the very simple "struct container" on which to

    Please read "vx_info" as "container" (or your preferred term). I
    decided to punt on the naming issue and copy Herbert :-).

    And also because the acronym "vx" makes the API look nice, at least to
    mine and Herbert's eyes, then when you go to the network virtualisation
    you get "nx_info", etc. However I'm thinking any of these terms might
    also be right:

    - "vserver" spelt in full
    - family
    - container
    - jail
    - task_ns (sort for namespace)

    Perhaps we can get a ruling from core team on this one, as it's
    aesthetics :-).


    This patch is simple, but does not handle SMP scalability very well
    (you'll get a lot of cacheline problems when you start actually using
    the container structure; the hashing helps a lot there), and does not
    provide functions such as looking up a container by ID etc. I think
    Herbert's context.c is a pretty nice basic set of functions for dealing
    with container-like things.

    Thanks for your feedback!
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-03-21 22:12    [W:0.023 / U:5.240 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site