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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [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]
  Powered by Linux