[Devel] Re: [RFC][PATCH] Do not set /proc inode->pid for non-pid-related inodes

Cedric Le Goater clg at fr.ibm.com
Thu Mar 22 06:14:48 PDT 2007


>> So I suggested to have a kthread be pid == 1 for each new pid namespace. 
>> the kthread can do the killing of all tasks if needed and will die when
>> the refcount on the pid namespace == 0.
>>
>> Would such a (rough) design be acceptable for mainline ?
> 
> The case that preserves existing semantics requires us to be able to
> run /sbin/init in a container.  Therefore pid 1 should be a user space
> process.

/sbin/init can't run without being pid == 1. hmm ? need to check. When we
have more of the pid namespace, it should be easier.
 
> So I don't think a design that doesn't allow us to run /sbin/init as
> in a container would be acceptable for mainline.

I agree that user space is assuming that /sbin/init has pid == 1 but don't 
you think that's a strong assumption ? 

on the kernel side we have is_init() so it shouldn't be an issue.

C.
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers




More information about the Devel mailing list