Re: RFC [patch 13/34] PID Virtualization Define new task_pid api

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is my preferred approach BY FAR.

Doing a <container,pid> approach is very natural, and avoids almost all issues. At most, you might want to have a new system call (most naturally just the one that is limited to the "init container" - it the one that we boot up with) that can specify both container and pid explicitly, and see all processes and access all processes. But all "normal" system calls would only ever operate within their container.

The fact is, we want "containers" anyway for any virtualization thing, ie vserver already adds them. And if we have containers, then it's very easy ("easyish") to split up the current static "pid_hash[]", "pidmap_array[]" and "pidmap_lock", and make them per-container, and have a pointer to the container for each "struct task_struct".
In fact this is almost what OpenVZ does for half a year, both containers and VPIDs. But it is very usefull to see process tree from host system. To be able to use std tools to manage containers from host (i.e. ps, kill, top, etc.). So it is much more convinient to have 2 pids. One globally unique, and one for container.

After that, there wouldn't even be a lot else to do. The normal system calls would just use their own container, and the (few) places that save away pid's for later (ie things that use "kill_proc_info_as_uid()" and "struct fown_struct" friends) would have to also squirrell away the container, but then you should be pretty much done.

Of course, you'll have to do the system calls to _create_ the containers in the first place, but that's at a higher level and involves much more than just the pid-space (ie a container would normally have more than just the uid mappings, it would have any network knowledge too etc - hostname, perhaps list of network devices associated with that context etc etc)

Kirill

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux