Dave Hansen <[email protected]> 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.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
