"Serge E. Hallyn" <[email protected]> writes:
> Hi,
>
> the lkml discussion on pid virtualization has been covering many of the
> issues both relating directly to pid virtualization, and relating to
> optimizations in the two specific implementations.
>
> However, if we're going to get anywhere, the first decision which we
> need to make is whether to go with a (container,pid), (pspace,pid) or
> equivalent pair like approach, or a virtualized pid approach. Linus had
> previously said that he prefers the former. Since there has been much
> discussion since then, I thought I'd try to recap the pros and cons of
> each approach, with the hope that the head Penguins will chime in one
> more time, after which we can hopefully focus our efforts.
Does anyone see problems with implementing this as series of namespaces?
If not we can move forward and start talking about pids, and the
other namespaces.
With respect to pids lets not get caught up in the implementation
details. Let's first get clear on what the semantics should be.
- Should the first pid in a pid space have pid 1?
- Should pid == 1 ignore signals, it doesn't have a handler for?
- Should any children of pid 1 be allowed to live when pid == 1 is killed?
- Should a process have some sort of global (on the machine identifier)?
- Should the pids in a pid space be visible from the outside?
- Should the parent of pid 1 be able to wait for it for it's
children?
- Is a completely disjoin pid space acceptable to anyone?
- What should the parent of pid == 1 see?
- Should a process not in the default pid space be able to create
another pid space?
- Should we be able to monitor a pid space from the outside?
- Should we be able to have processes enter a pid space?
- Do we need to be able to be able to ptrace/kill individual processes
in a pid space, from the outside, and why?
- After migration what identifiers should the tasks have?
If we can answer these kinds of questions we can likely focus in
on what the implementation should look like. So far I have not
seen a question that could not be implemented with a (pspace, pid)/pid
or a vpid/pid implementation.
I think it is safe to say that from the inside things should look to
processes just as they do now. Which answers a lot of those
questions. But it still leaves a lot open.
Eric
-
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]
