Quoting chenhanxiao@xxxxxxxxxxxxxx (chenhanxiao@xxxxxxxxxxxxxx): > > > > -----Original Message----- > > From: Serge Hallyn [mailto:serge.hallyn@xxxxxxxxxx] > > Sent: Friday, August 08, 2014 12:12 AM > > To: Chen, Hanxiao/陈 晗霄 > > > > > How much more kernel space does this take up? > > > > > > > > > > Only first process when creating new ns will be add here. > > > So there would not so many items. > > > > Oh, I see. > > > > > > Is there an easy way to go from a pid in your own namespace > > > > to its proper node under /proc/nspid? I.e. if I am interested > > > > in pid 9987, which happens to be pid 5 inside a container in > > > > ns2, and then I want to know what it means when it (pid 9987) > > > > is talking about 'pid 10'. Is there a link under /proc/9987/ > > > > leading to /proc/nspid/ns2/5 ? > > > > > > If you want to query pid 9987, you could: > > > a) readlink /proc/9987/ns/pid > > > b) refer to /proc/nspid/ns$(inum)/ns$(inum).. > > > c) Also the link to the 1st new ns process could be found under ns$(inum). > > > > This is good. Let's go with it. > > OK > > > > > > Or as what you said above, > > > > Nah. Let's not change /proc/PID/ns/pid. > > > > > > This sure does seem the simplest route. But it actually still > > > > does not provide us an easy answer to "what does pid 9987 mean > > > > when it talks about pid 10?". > > > > > > Do you mean: > > > init_pid_ns ns1 ns2 > > > 9987 10 5 > > > Neither getnspid syscall nor proc/PID/status expansion > > > could answer this without hierarchy information. > > > For users in init_pid_ns, getnspid needs > > > an observer pid live and only live in ns1, > > > > Yes, good point. That's a definite disadvantage of getnspid > > compared to your proc approach. > > > > > or we should call getnspid in ns1. > > > See below for more. > > > > > > > > > > > > 2. Advantage of procfs solution > > > > > a) easy to use: > > > > > getnspid(6, 10) -> (10, 9, 10) > > > > > or > > > > > getnspid(10, ns1_fd, ns0_fd) -> 9 > > > > > getnspid(10, ns2_fd, ns0_fd) -> 10 > > > > > > > > > > And we could also get it by: > > > > > cat /proc/10/status | grep NSpid: > > > > > NSpid: 10 9 10 > > > > > ... > > > > > > > > It looks nice, but I'm not convinced it gives us the info we > > > > need. > > > > > > > > It's certainly possible that I've just not thought it through > > > > enough. > > > > > > > > Question: are you proposing this (/proc/pid/status expansion) as an > > > > alternative to /proc/nspid, or are they meant to be complementary? > > > > > > > > > > We want /proc/nspid as a complement for pid translation. > > > > Ok. > > > > > Ex: > > > init_pid_ns ns1 ns2 > > > t1 2 > > > t2 `- 3 1 > > > t3 `- 4 `- 5 1 > > > t4 `-6 `-8 `-9 > > > t5 `-10 `-9 `-10 > > > Suppose we were in init_pid_ns: > > > getnspid(9,4)->6 (t4) > > > getnspid(9,3)->10(t5) > > > We knew t2 in ns1 and t3 in ns2, but we don't know their relationship. > > > If we want to query pid 9 in ns1, we could use getnspid(9,3)->10(t5) > > > but the pre-requisite is that we know ns2 is the child of ns1. > > > > I like your proc approach. Do you have an implementation? > > Thanks for your comments. > I'm preparing the pidns hierarchy patch. > It seems that it's not easy to carry it out. :) Not entirely surprised. Please do send patches earlier rather than later to avoid going down a path that someone's going to nack anyway. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
