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


-
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/