Re: [RFC][PATCH 1/5] Virtualization/containers: startup

[Kirill Korotaev <dev@sw.ru>]

Hello,

> I worry that using something like "vps" obfuscates the real meaning a
> bit.  The reason that "owner_vps" doesn't sound weird is that people, by
> default, usually won't understand what a "vps" is.
container or context sounds the same :) it is impossible to feel this 
notion naturally without getting into details. IMHO.

> (if you like acronyms a lot, I'm sure I can find a job for you at IBM or
> in the US military :)
We can talk about it separetely :)))

>>Please, also note, in OpenVZ we have 2 pointers on task_struct:
>>One is owner of a task (owner_env), 2nd is a current context (exec_env). 
>>exec_env pointer is used to avoid adding of additional argument to all 
>>the functions where current context is required.
> 
> That makes sense.  However, are there many cases in the kernel where a
> task ends up doing something temporary like this:
> 
> 	tsk->exec_vnc = bar;
> 	do_something_here(task);
> 	tsk->exec_vnc = foo;
> 
> If that's the case very often, we probably want to change the APIs, just
> to make the common action explicit.  If it never happens, or is a
> rarity, I think it should be just fine.
It is quite rare. In IRQ, softIRQ, TCP/IP stack and some timers. Not much.

>>VPS ID is passed to/from user space APIs and when you have a cluster 
>>with different archs and VPSs it is better to have something in common 
>>for managing this.
> I guess it does keep you from running into issues with mixing 32 and
> 64-bit processes.  But, haven't we solved those problems already?  Is it
> just a pain?
VPSs can live in clusters. It is good to have one VPS ID space.

Kirill