[Devel] Re: [RFC][PATCH] Do not set /proc inode->pid for non-pid-related inodes
Eric W. Biederman
ebiederm at xmission.com
Mon Mar 26 10:24:06 PDT 2007
"Serge E. Hallyn" <serue at us.ibm.com> writes:
> The way I'm testing pidspaces right now is
>
> ns_exec -c -p /usr/sbin/sshd -p 9999
>
> in which case sshd is pid1. Works fine...
>
> Would it be very limiting to have the first process have to stick
> around? (I'm asking, not criticizing - it's *my* preference that we
> allow pid==1 to exit, but if that's really not advantageous then
> maybe it's not worth fixing the ugly pieces that require it right
> now - afaik right now that's only the fact that PROC_INODE(/proc)->pid
> points to the struct pid for pidnr==1)
The /proc part is easy to fix. All I want to see there is that
we do the right thing with pid related files. When the pid namespace
is empty.
The practical reason for only allowing a pid namespace while pid == 1
exists, is something much more simple.
pid == 1 must exists today. We get into an extension of the semantics
if we allow the case where pid == 1 exists. Semantic extensions
can be very tricky, and we are way to early to see what the impact
of such a semantic extension would be.
Therefore I request that we get a correct and work pid namespace
before we try and extend things.
I also request that until questions like this are settles we leave the
whole thing CONFIG_EXPERIMENTAL.
I have yet to see how we are going to implement things such as
kill -1. And the other changes. There are huge chunks of
functionality that we haven't gotten to yet.
Eric
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
More information about the Devel
mailing list