Re: [PATCH 1/2v6] procfs: show hierarchy of pid namespace

[Richard Weinberger]

Am 06.11.2014 um 06:48 schrieb Chen, Hanxiao:
> 
> 
>> -----Original Message-----
>> From: Richard Weinberger [mailto:richard@xxxxxx]
>> Sent: Wednesday, November 05, 2014 8:52 PM
>> To: Serge E. Hallyn
>> Cc: Chen, Hanxiao/陈 晗霄; Eric W. Biederman; Serge Hallyn; Oleg Nesterov;
>> containers@xxxxxxxxxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Mateusz
>> Guzik; David Howells
>> Subject: Re: [PATCH 1/2v6] procfs: show hierarchy of pid namespace
>>
>> Am 05.11.2014 um 13:41 schrieb Serge E. Hallyn:
>>> Quoting Richard Weinberger (richard@xxxxxx):
>>>> Am 05.11.2014 um 11:41 schrieb Chen Hanxiao:
>>>>> We lack of pid hierarchy information, and this will lead to:
>>>>> a) we don't know pids' relationship, who is whose child:
>>>>>    /proc/PID/ns/pid only tell us whether two pids live in different ns
>>>>> b) bring trouble to nested lxc container check/restore/migration
>>>>> c) bring trouble to pid translation between containers;
>>>>>
>>>>> This patch will show the hierarchy of pid namespace
>>>>> by pidns_hierarchy like:
>>>>>
>>>>> [root@localhost ~]#cat /proc/pidns_hierarchy
>>>>> 18060 18102 1534
>>>>> 18060 18102 1600
>>>>> 1550
>>>>
>>>> Hmm, what about printing the pid hierarchy in the same way as
>> /proc/self/mountinfo
>>>> does with mount namespaces?
>>>> Your current approach is not bad but we should really try to be consistent
>> with existing
>>>> sources of information.
>>>
>>> Good point.  How would you structure it to make it look mor elike mountinfo?
>>> Adding the pidns inode number (in place of a mount sequence number) might be
>>> useful, but it sounds like you have a more concrete idea?
>>
>> Just list <init_PID> <parent_of_init_PID>. This way we have exactly one
>> information record per line and always exactly two columns to parse.
>>
>> e.g.
>> [root@localhost ~]#cat /proc/pidns_hierarchy
>> 1550 1
>> 18060 1
>> 18102 18060
>> 1534 18102
>> 1600 18102
>>
> But this style lacks of *level* information:

It does not.

> Ex:
> 1->18060->18102->1600->1700
> If we want to check the 1700's level in pid ns
> Style 1:
> 18060 18102 1600 1700
> 
> Style 2:
> 18060 1
> 18102 18060
> 1600 18102
> 1700 1600
> 
> If we had a little more containers,
> Style 2 would not be clear enough.
> 1 line vs $(PID level) line

Any trivial program can find out the level of nesting.

> If there were no more related information to show,
> I think style 1 looks better.

It is not about looking better, it is about parsing and being consistent with existing
interfaces. /proc/pidns_hierarchy will be mostly read by *programs*, not humans.
/proc/ has already too many horrible to parse files, please don't add another one.
This is also why sysfs has the one-value-per-file rule.

If it makes you feel better you can add a third column to the output which indicates
the nesting level (or the distance to the initial pidns) . i.e.
Style 2:
18060 1 1
18102 18060 2
1600 18102 3
1700 1600 4

Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/