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

    > On Tue, 2006-03-21 at 18:13 +1200, Sam Vilain wrote:
    >> Here is a work in progress of trying to extract some the core vserver
    >> architecture and present it as an incremental set of patches.
    > Hi Sam,
    > These patches are certainly getting better and better broken out all the
    > time. Nice work.
    > But, I worry that they just aren't generic enough yet. I don't see any
    > response from any of the other "container/namespace/vps" people. I fear
    > that this means that they don't look broadly useful enough, yet.

    Not broadly useful is certainly my impression.
    It feels to me like these patches are simply doing too much.

    > 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.

    I certainly have not. I do feel that developing this just from the
    top down is the wrong way to do this. In some of the preliminary
    patches we have found several pieces of code that we will have to
    touch that is currently in need of a cleanup. That is why I have
    been cleaning up /proc. sysctl is in need of similar treatment
    but is in less bad shape.

    Part of it is that I have stopped to look more closely at what
    other people are doing and to look at alternative implementations.

    One interesting thing I have manged to do is by using ptrace I
    have implemented enter for the existing filesystem namespaces
    without having to modify the kernel. This at least says
    that enter and debugging are two faces of the same coin.

    > 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 that is the case on the fundamentals. I think with pids
    I am an inch away from implementing a pid namespace that is both
    recursive, efficient, and can map all of the pids into another pid
    space if that is desirable. Plus I can merge most of it incrementally
    in the existing kernel, before I even allow for multiple pid spaces.

    Which should reduce the patch for multiple pid namespaces to something
    reasonable to talk about.

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

    I guess my problem there is that isn't something on which to build
    that is something to hang things off of.

    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-22 07:48    [W:0.028 / U:6.956 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site