Re: [RFC][PATCH 04/20] pspace: Allow multiple instaces of the processid namespace

[Kirill Korotaev]

> > 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/