Re: [RFC] [PATCH 0/7] Some basic vserver infrastructure

[Kirill Korotaev]

Hello,

> > 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.
Exactly!
These patches are really too big and can't be called clean... naming,
bunch of debug etc. I can post the same amount of OpenVZ stuf and
Herbert will claim his code is more clear after that.
Also these patches contradict to what was discussed before: different
name spaces for each subsystem.

> > 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.
Eric, though I suggest to postpone proc and sysctl a bit, can you share
me your vision of /proc and /sysctl virtualization a bit?
A good way to handle them IMHO is to make fully virtual, i.e. each
namespace should have an own set of sysctl or proc tree.

> Part of it is that I have stopped to look more closely at what
> other people are doing and to look at alternative implementations.
If you need any help with it in OpenVZ, feel free to ask. We have
broken-out patches for recent 2.6.16 kernel.

> 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.
Hmmm, strange claim/conclusion... /dev/kmem allows to change namespaces
also :) and even to obtain root priviliges if needed... :)

> > 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.
Eric, let's not compare approaches with inches :)
As you remember your PID namespaces doesn't suite us well... :(

Thanks,
Kirill

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/