lkml.org 
[lkml]   [2006]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH 04/20] pspace: Allow multiple instaces of the process id namespace
>>And we are too cycled on PIDs. Why? I think this is the most minor 
>>feature which can easily live out of mainstream if needed, while
>>virtualization is the main goal.
>
>
> although I could be totally ignorant regarding the PID
> stuff, it seems to me that it pretty well reflects the
> requirements for virtualization in general, while being
> simple enough to check/test several solutions ...
>
> why? simple: it reflects the way 'containers' work in
> general, it has all the issues with administration and
> setup, similar to 'guests' (it requires some management
> and access from outside, while providing security and
> isolation inside), containers could be easily built on
> top of that or as an addition to the pid space structures
> at the same time it's easy to test, and issues will show
> up quite early, so that they can be discussed and, if
> necessary, solved without rewriting an entire framework.
I would disagree with you. These discussions IMHO led us to the wrong
direction.

Can I ask a bunch of questions which are related to other virtualization
issues, but which are not addressed by Eric anyhow?

- How are you planning to make hierarchical namespaces for such
resources as IPC? Sockets? Unix sockets?
Process tree is hierarchical by it's nature. But what is heirarchical
IPC and other resources?
And no one ever told me why we need heierarchy at all. No any _real_ use
cases. But it's ok.

- Eric wants to introduce name spaces, but totally forgots how much they
are tied with each other. IPC refers to netlinks, network refers to proc
and sysctl, etc. It is some rare cases when you will be able to use
namespaces without full OpenVZ/vserver containers.
But yes, you are right it will be quite easy for us to use containers on
top of namespaces :)

- How long these namespaces live? And which management interface each of
them will have?
For example, can you destroy some namespace? Or it is automatically
destroyed when the last reference to it is dropped? This is not that
simple question as it may seem to be, especially taking into account
that some namespaces can live longer (e.g. time wait buckets should live
some time after container died; or shm which also can die in a foreign
context...).

So I really hate that we concentrated on discussion of VPIDs, while
there are more general and global questions on the whole virtualization
itself.

> now that you mention it, maybe we should have a few
> rounds how those 'generic' container syscalls would
> look like?

First of all, I don't think syscalls like
"do_something and exec" should be introduced.

Next, these syscalls interfaces can be introduced only after we
discussed the _general_ concepts, like: how these containers exist,
live, are created, waited and so on. But this is impossible to discuss
on PID example only. Because:
1. pids are directly related to process lifetime. no much issues here.
2. pids are hierarchical by its nature.
3. there are much more approaches here, then in network for example.

Kirill

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

\
 
 \ /
  Last update: 2006-02-20 12:48    [from the cache]
©2003-2011 Jasper Spaans