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

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

 



>> 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@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/containers


[Index of Archives]     [Cgroups]     [Netdev]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux