Home » Mailing lists » Devel » [RFC][PATCH] VPIDs: Virtualization of PIDs (OpenVZ approach)
Re: [RFC][PATCH] VPIDs: Virtualization of PIDs (OpenVZ approach) [message #1211 is a reply to message #1197] |
Fri, 03 February 2006 12:45  |
Alexey Kuznetsov
Messages: 18 Registered: February 2006
|
Junior Member |
|
|
Hello!
> - hierarchical structure (it's flat, only one level)
Er... if I understand the question correctly, it is not flat,
it is rather universal.
The main idea of the VPID approach is that it _preserves_ existing
logic completely, all the references, interprocess linkage and process
grouping are made using usual unique pids.
Virtual pids are just the numbers, which user level applications see.
Of course, they depend on the point where you view from.
> - a proper administration scheme
There is nothing to administrate. pids are generated and assigned
automatically.
Virtual pids come to the game only when you move a process from
one host to another, new process is created with do_fork_pid(),
which assignes the same virtual pid and generates brand new global pid,
unique for destination host.
> - a 'view' into the child pid spaces
In order to access a virtual pid space the process must enter
the corresponding container. You are not going to add the whole set
of syscalls, which use not only pid but also a container identifier, right?
For purpose of debugging, vpids are shown /proc/*/status, it is enough.
> - handling of inter context signalling
Not an issue. All the inter-container communication is made using
global pids.
It is necessary to emphasize again, VPID patch _preserves_ currently
existing capabilities: all the processes in all the containers
can be accessed by global pids. F.e. plain "ps axf" executed in "initial
container" shows the whole process tree.
It is one of main points: "virtual" pids are not used to _limit_ access,
is not a "no go" thing, it allows to go on when we have to reinstate
VPS at another host. Access checks are not based on some pids, they
are defined by policy rules, which are checked after corresponding
objects (tasks in our case) are found.
> and, more important, it does not deal with the existing
> issues and error cases, where references to pids, tasks,
> task groups and sessions aren't handled properly ...
I am sorry, I am not aware about such bugs (expect for a few well-known
cases, when someone holds a pid, which can remain stray and be recycled.
But it is apparently orthogonal to the problem under duscussion).
If they do exist they apparently must be fixed asap not depending
on anything else.
Alexey
|
|
|
 |
|
[RFC][PATCH] VPIDs: Virtualization of PIDs (OpenVZ approach)
|
 |
|
[RFC][PATCH 1/7] VPIDs: add VPID config option
By: dev on Thu, 02 February 2006 16:16
|
 |
|
[RFC][PATCH 2/7] VPIDs: pid/vpid conversions
By: dev on Thu, 02 February 2006 16:21
|
 |
|
Re: [RFC][PATCH 2/7] VPIDs: pid/vpid conversions
By: ebiederm on Wed, 08 February 2006 20:29
|
 |
|
Re: [RFC][PATCH 2/7] VPIDs: pid/vpid conversions
|
 |
|
Re: [RFC][PATCH 2/7] VPIDs: pid/vpid conversions
By: ebiederm on Thu, 09 February 2006 00:37
|
 |
|
Re: [RFC][PATCH 2/7] VPIDs: pid/vpid conversions
|
 |
|
Re: [RFC][PATCH 2/7] VPIDs: pid/vpid conversions
By: ebiederm on Thu, 09 February 2006 01:36
|
 |
|
Re: [RFC][PATCH 2/7] VPIDs: pid/vpid conversions
By: serue on Thu, 09 February 2006 02:51
|
 |
|
Re: [RFC][PATCH 2/7] VPIDs: pid/vpid conversions
|
 |
|
Re: [RFC][PATCH 2/7] VPIDs: pid/vpid conversions
By: ebiederm on Thu, 09 February 2006 19:22
|
 |
|
Re: [RFC][PATCH 2/7] VPIDs: pid/vpid conversions
By: dev on Mon, 20 February 2006 14:55
|
 |
|
Re: [RFC][PATCH 2/7] VPIDs: pid/vpid conversions
|
 |
|
Re: [RFC][PATCH 2/7] VPIDs: pid/vpid conversions
By: dev on Tue, 21 February 2006 16:17
|
 |
|
Re: [RFC][PATCH 2/7] VPIDs: pid/vpid conversions
|
 |
|
[RFC][PATCH 3/7] VPIDs: fork modifications
By: dev on Thu, 02 February 2006 16:24
|
 |
|
Re: [RFC][PATCH 3/7] VPIDs: fork modifications
|
 |
|
[RFC][PATCH 4/7] VPIDs: vpid macros in non-VPID case
|
 |
|
[RFC][PATCH 5/7] VPIDs: vpid/pid conversion in VPID enabled case
|
 |
|
Re: [RFC][PATCH 5/7] VPIDs: vpid/pid conversion in VPID enabled case
|
 |
|
Re: [RFC][PATCH 5/7] VPIDs: vpid/pid conversion in VPID enabled case
By: serue on Thu, 02 February 2006 19:29
|
 |
|
Re: [RFC][PATCH 5/7] VPIDs: vpid/pid conversion in VPID enabled case
|
 |
|
Re: [RFC][PATCH 5/7] VPIDs: vpid/pid conversion in VPID enabled case
|
 |
|
Re: [RFC][PATCH 5/7] VPIDs: vpid/pid conversion in VPID enabled case
|
 |
|
Re: [RFC][PATCH 5/7] VPIDs: vpid/pid conversion in VPID enabled case
|
 |
|
Re: [RFC][PATCH 5/7] VPIDs: vpid/pid conversion in VPID enabled case
|
 |
|
Re: [RFC][PATCH 5/7] VPIDs: vpid/pid conversion in VPID enabled case
|
 |
|
Re: [RFC][PATCH 5/7] VPIDs: vpid/pid conversion in VPID enabled case
|
 |
|
Re: [RFC][PATCH 5/7] VPIDs: vpid/pid conversion in VPID enabled case
By: serue on Mon, 06 February 2006 14:51
|
 |
|
Re: [RFC][PATCH 5/7] VPIDs: vpid/pid conversion in VPID enabled case
|
 |
|
Re: [RFC][PATCH 5/7] VPIDs: vpid/pid conversion in VPID enabled case
By: serue on Mon, 06 February 2006 16:24
|
 |
|
Re: [RFC][PATCH 5/7] VPIDs: vpid/pid conversion in VPID enabled case
|
 |
|
Re: [RFC][PATCH 5/7] VPIDs: vpid/pid conversion in VPID enabled case
By: dev on Tue, 07 February 2006 11:42
|
 |
|
Re: [RFC][PATCH 5/7] VPIDs: vpid/pid conversion in VPID enabled case
|
 |
|
Re: [RFC][PATCH 5/7] VPIDs: vpid/pid conversion in VPID enabled case
|
 |
|
Re: [RFC][PATCH 5/7] VPIDs: vpid/pid conversion in VPID enabled case
By: dev on Fri, 03 February 2006 14:03
|
 |
|
Re: [RFC][PATCH 5/7] VPIDs: vpid/pid conversion in VPID enabled case
|
 |
|
Re: [RFC][PATCH 5/7] VPIDs: vpid/pid conversion in VPID enabled case
|
 |
|
[RFC][PATCH 6/7] VPIDs: small proc VPID export
|
 |
|
[RFC][PATCH 7/7] VPIDs: required VPS interface for VPIDs
|
 |
|
Re: [RFC][PATCH] VPIDs: Virtualization of PIDs (OpenVZ approach)
|
 |
|
Re: [RFC][PATCH] VPIDs: Virtualization of PIDs (OpenVZ approach)
|
 |
|
Re: [RFC][PATCH] VPIDs: Virtualization of PIDs (OpenVZ approach)
|
Goto Forum:
Current Time: Sat Aug 30 11:41:11 GMT 2025
Total time taken to generate the page: 0.11582 seconds
|