Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): > Glauber Costa <glommer@xxxxxxxxxxxxx> writes: > >> The twist of course is what does a boot mean. If we are really after > >> machine boots than the current behavior is correct. > >> > >> Looking back in the archives the desired behavior appears to be a value > >> that can be used to see if a pid value must be stale. > >> > >> As a stale pid detector boot_id is pretty lousy. Pids can still be > >> reused. > >> > >> Still a role as a stale pid detector makes it clear which namespace > >> boot_id should be in and how we should treat boot_id upon migration. > >> > >> You can only serve as a stale pid detector if you are in the pid > >> namespace. > >> > >> So at this point patches are welcome. Hopefully with a summary > >> of the discussion. > >> > >> Eric > >> > > > > Your discussion about boot_id being a limited solution is totally valid. > > But it is orthogonal to the question of whether or not a container > > should have it. > > The important part is that boot_id as originally conceived is an > identifier to be used in conjunction with pids. Therefore boot_id is a > proper pid_namespace component, and there are no semantic problems with > putting it in the kernel. > > > I took a look at this, and I think the kernel should be in perfect > > position to do it. > > Agreed. > > > boot_id as a pid namespace id is a very well defined concept. > > Agreed. > > A reference to the history and the definition needs to be in the patch > description. Huh. I must have glossed over that part of this thread. If you both agree to that, then I'm fine with it - I'll go read the history when the new patch comes by. thanks, -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
