Messages in this thread | | | Subject | Re: [RFC][PATCH 20/20] proc: Update /proc to support multiple pid spaces. | From | (Eric W. Biederman) | Date | Sat, 11 Feb 2006 03:10:16 -0700 |
| |
Kirill Korotaev <dev@sw.ru> writes:
> Hello, > >> This patch does a couple of things. >> - It splits proc into proc and proc_sysinfo >> - It adds pspace support to proc >> - It adds getattr methods to ensure proc has the proper hard link count. >> - It increases the size of a couple of buffers by one to avoid buffer overflow >> - It moves /proc/mounts and /proc/loadavg into the proc filesystem from > proc_sysinfo >> Sorry for the big patch. When I start feeding this changes seriously I will >> split this patch. >> The split of /proc into mutliple filesystems works well however it comes >> with one downsides. There are now some directories where cd -P <subdir>/.. >> is not a noop. Basically it is doing the equivalent of following symlinks >> into an internal kernel mount. It is well defined and safe behaviour but >> I'm not certain if it is desirable. >> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> > > This one is really ugly.
It is certainly to much at one time, and the code while semanticly interesting is still has significant issues with the implementation. But a lot of the ugliness is inherent in the current implementation of /proc and not what I am trying to do with it.
> And it is also controversial to your own idea of having separate namespaces, > but introduces a pointer to proc_mnt in pspace.
An instance of /proc being connected to a pid space is perfectly natural. /proc is after all the filesystem that reports what is in a pspace.
I freely admit the way I am using the internal mount of proc is wrong, and is something that needs to be resolved before I submit this for kernel inclusion. I was attempting to solve the problem of having duplicate dcache entries in my recursive structure. Unfortunately it was one of those clever solutions that only gets you 99% of the way to where you want to go.
> You have many namespaces to which task_struct refers. > Do you want proc to work in any configuration of namespaces? Yes.
> Then you can't have pointers to proc_mnt from namespaces. > Well, I understand that proc is the most painfull for you... yeah...
proc is the painful for any pid change in how pids are dealt with. So far I have not seen a single implementation that cleanly and correctly addresses all of the issues (including mine :)
Eric
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |