Konstantin Khlebnikov <khlebni...@yandex-team.ru> writes: > On 21.09.2015 17:22, Serge E. Hallyn wrote: >> >> So please implement it, as Eric suggested, using the ns inode fds >> instead of racy pid_t hints for namespaces. >> > > I don't want to loose simple way to use it. > Sometimes caller cannot prevent races (task its child or > locked with with ptrace) or it don't care about them. > > What about this design: > > pid_t getvpid(pid_t pid, pid_t source, pid_t target) > > pid > 0 - get vpid of task > pid = 0 - current pid (= just for symmetry =) > pid < 0 - get vpid of parent task (ppid of -pid) > [ that's really useful for poking isolated pidns ] > source/target > 0 - pid of source/target task > source/target = 0 - use current as source/target > source/target < 0 - use pidns fd (1-arg) as source/target > > or the same but without =0 sugar: > > pid > 0 - get vpid of task > pid < 0 - get vpid of parent task (ppid of -arg) > source/target > 0 - pid of source/target task > source/target <= 0 - use pidns fd (-arg) as source/target > > libc caches current pid, extra getpid shouldn't be a problem.
Yuck. An invalid fd like for saying use the current pid namespace is fine. Using pids to identify namespaces yuck just yuck. That just seems to add complexity for no gain except to make programs buggier. We have a couple of old interfaces that use pids because pids were the the best we had, but at this point I don't see anything at all that even suggests that pids are a good choice for identifying namespaces. If performance is important than caching file descriptors should be trivial. If performance is not important it should not be hard to open "/proc/<pid>/ns/pid". I do not see the gain of using pids in this interface except to confuse people, and make the interface brittle. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
