[PATCH] [RFC] c/r: Add UTS support
mikew at google.com
Wed Mar 18 17:46:07 PDT 2009
Eric W. Biederman wrote:
> Mike Waychison <mikew at google.com> writes:
>> Cedric Le Goater wrote:
>>> Dan Smith wrote:
>>>> SH> (Note that in Dan's next version, he did move unshare into
>>>> SH> userspace)
>>>> The idealist in me still wants it to be in the kernel. However, after
>>>> seeing it done I agree that it's the right thing to do, at least in
>>>> this case.
>>> I would say in all cases.
>>> as you can't unshare(CLONE_NEWPID),
>> Is there a particular reason the above doesn't work? I made an attempt to
>> implement it a while back, but haven't convinced myself that signals and
>> re-attaching a new struct pid to a running task is correct.
> Last time I was thinking about this I figured unsharing a pid namespace would
> simply place it's children in a different pid namespace, not the originating
> Would that semantic be useful? It would certainly be a lot less effort than
> changing the pid on a running process correctly.
Hmm, that would be a little odd. I think getting the unsharing task to
become pid 1 is a bit easier to understand and it makes it clear which
task is the reaper for the new namespace. Otherwise the first child
becomes pid 1 but it isn't the reaper.
More information about the Containers