[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140623133230.GA31817@mail.hallyn.com>
Date: Mon, 23 Jun 2014 15:32:30 +0200
From: "Serge E. Hallyn" <serge@...lyn.com>
To: "chenhanxiao@...fujitsu.com" <chenhanxiao@...fujitsu.com>
Cc: Richard Weinberger <richard@....at>,
"containers@...ts.linux-foundation.org"
<containers@...ts.linux-foundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Pavel Emelyanov <xemul@...allels.com>,
"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
Serge Hallyn <serge.hallyn@...ntu.com>,
Oleg Nesterov <oleg@...hat.com>,
David Howells <dhowells@...hat.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH v2] ns: introduce getnspid syscall
Quoting chenhanxiao@...fujitsu.com (chenhanxiao@...fujitsu.com):
> Hi
>
> > -----Original Message-----
> > From: Richard Weinberger [mailto:richard@....at]
> > Sent: Friday, June 20, 2014 7:02 PM
> > To: Chen, Hanxiao/陈 晗霄; containers@...ts.linux-foundation.org;
> > linux-kernel@...r.kernel.org
> > Cc: Eric W. Biederman; Serge Hallyn; Daniel P. Berrange; Oleg Nesterov; Al Viro;
> > David Howells; Pavel Emelyanov; Vasiliy Kulikov; Gotou, Yasunori/五島 康文;
> > linux-api@...r.kernel.org
> > Subject: Re: [PATCH v2] ns: introduce getnspid syscall
> >
> > Am 20.06.2014 12:18, schrieb Chen Hanxiao:
> > > We need a direct method of getting the pid inside containers.
> > > If some issues occurred inside container guest, host user
> > > could not know which process is in trouble just by guest pid:
> > > the users of container guest only knew the pid inside containers.
> > > This will bring obstacle for trouble shooting.
> > >
> > > int getnspid(pid_t pid, int fd1, int fd2);
> > >
> > > pid: the pid number need to be translated.
> > >
> > > fd: a file descriptor referring to one of
> > > the namespace entries in a /proc/[pid]/ns/pid.
> > > fd1 for destination ns(ns1), where the pid came from.
> > > fd2 for reference ns(ns2), while fd2 = -2 means for current ns.
> > >
> > > return value:
> > > >0 : translated pid in ns1(fd1) seen from ns2(fd2).
> > > <=0: on failure.
> > >
> >
> > I don't think that adding a new system call for this is a good solution.
> > We need a more generic way. I bet people are interested in more than just PID
> > numbers.
>
> Could you please give some hints on how to expand this interface?
>
> >
> > I agree with Eric that a procfs solution is more appropriate.
> >
>
> Procfs is a good solution, but syscall is not bad though.
I might be inclined to agree, except that in this case you are still
needing mounted procfs anyway to get the proc/$pid/ns/pid fds.
I'm sorry, I've not been watching this thread, so this probably has been
considered and decided against, but I'm going to ask anyway. Keeping
in mind both checkpoint-restart and and introspection for use in a
setns'd commend, why not make it
pid_t getnspid(pid_t query_pid, pid_t observer_pid)
which returns the process id of query_pid as seen from observer_pid's
pidns?
> Procfs works for me, but that seems could not fit
> Pavel's requirement.
> His opinion is that a syscall is a more generic interface
> than proc files, and also very helpful.
> And syscall could tell whether a pid lives in a specific pid namespace,
> much convenient than procfs.
>
> Thanks,
> - Chen
> _______________________________________________
> Containers mailing list
> Containers@...ts.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/containers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists