Messages in this thread | | | Date | Mon, 06 Feb 2006 19:51:43 +0300 | From | Kirill Korotaev <> | Subject | Re: [RFC][PATCH 1/5] Virtualization/containers: startup |
| |
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/
| |