public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Kirill Korotaev <dev@sw.ru>
To: Dave Hansen <haveblue@us.ibm.com>
Cc: Linus Torvalds <torvalds@osdl.org>,
	Kirill Korotaev <dev@openvz.org>, Andrew Morton <akpm@osdl.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	frankeh@watson.ibm.com, clg@fr.ibm.com, greg@kroah.com,
	alan@lxorguk.ukuu.org.uk, serue@us.ibm.com, arjan@infradead.org,
	Rik van Riel <riel@redhat.com>,
	Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
	Andrey Savochkin <saw@sawoct.com>,
	devel@openvz.org, Pavel Emelianov <xemul@sw.ru>
Subject: Re: [RFC][PATCH 1/5] Virtualization/containers: startup
Date: Sun, 05 Feb 2006 18:05:44 +0300	[thread overview]
Message-ID: <43E61448.7010704@sw.ru> (raw)
In-Reply-To: <1138991641.6189.37.camel@localhost.localdomain>

> I just did a global s/vps/container/ and it looks pretty reasonable, at
> least from my point of view.
> 
> Couple of minor naming nitpick questions, though.  Is vps/container_info
> really what we want to call it?  It seems to me to be the basis for a
> real "container", without the _info part.
Can be ommited.

> "tsk->owner_container"  That makes it sound like a pointer to the "task
> owner's container".  How about "owning_container"?  The "container
> owning this task".  Or, maybe just "container"?
This is why I don't like "container" name.

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.

Linus, does such approach makes sense to you or you prefer us to add 
additional args to functions where container pointer is needed? This 
looks undersiable for embedded guys and increases stack usage/code size 
when virtualization is off, which doesn't look good for me.

> Any particular reason for the "u32 id" in the vps_info struct as opposed
> to one of the more generic types?  Do we want to abstract this one in
> the same way we do pid_t?
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.

> The "host" in "host_container_info" doesn't mean much to me.  Though, I
> guess it has some context in the UML space.  Would "init_container_info"
> or "root_container_info" be more descriptive?
init_container?
(Again, this is why container doesn't sound for me :) )

> Lastly, is this a place for krefs?  I don't see a real need for a
> destructor yet, but the idea is fresh in my mind.
I don't see much need for krefs, do you?
In OpenVZ we have 2-level refcounting (mentioned recently by Linus as in 
mm). Process counter is used to decide when container should 
collapse/cleanuped and real refcounter is used to free the structures 
which can be referenced from somewhere else.

Also there is some probability that use of krefs will result in sysfs :)))

> How does the attached patch look?
I will resend all 5 patches tomorrow. And maybe more.

Kirill

  parent reply	other threads:[~2006-02-05 15:07 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-03 16:58 [RFC][PATCH 1/5] Virtualization/containers: startup Kirill Korotaev
2006-02-03 17:03 ` [RFC][PATCH 2/5] Virtualization/containers: UIDs Kirill Korotaev
2006-02-03 17:06 ` [RFC][PATCH 3/5] Virtualization/containers: UTSNAME Kirill Korotaev
2006-02-06  8:21   ` Eric W. Biederman
2006-02-06  8:53     ` Kirill Korotaev
2006-02-03 17:15 ` [RFC][PATCH 1/5] Virtualization/containers: startup Linus Torvalds
2006-02-03 17:22   ` Kirill Korotaev
2006-02-03 17:49     ` Linus Torvalds
2006-02-03 18:34       ` Dave Hansen
2006-02-03 18:55         ` Jeff Garzik
2006-02-03 19:18         ` Hubertus Franke
2006-02-03 19:56         ` Hubertus Franke
2006-02-03 20:19         ` Greg KH
2006-02-03 20:34           ` Hubertus Franke
2006-02-05 15:11             ` Kirill Korotaev
2006-02-05 15:39               ` Hubertus Franke
2006-02-06  9:08                 ` Kirill Korotaev
2006-02-06 22:31               ` Cedric Le Goater
2006-02-07 12:28                 ` Kirill Korotaev
2006-02-05 15:10           ` Kirill Korotaev
2006-02-05 15:05         ` Kirill Korotaev [this message]
2006-02-06 16:35           ` Dave Hansen
2006-02-06 16:51             ` Kirill Korotaev
2006-02-06 16:56           ` Linus Torvalds
2006-02-06 17:21             ` Kirill Korotaev
2006-02-07  0:28             ` Sam Vilain
2006-02-07 12:21               ` Kirill Korotaev
2006-02-07 22:21                 ` Sam Vilain
2006-02-20 11:56                   ` Kirill Korotaev
2006-02-03 18:36       ` Summary: PID virtualization , Containers, Migration Hubertus Franke
2006-02-03 18:36       ` [RFC][PATCH 1/5] Virtualization/containers: startup Rik van Riel
2006-02-05 14:52       ` Kirill Korotaev
2006-02-06  8:39       ` Eric W. Biederman
2006-02-06  9:00         ` Kirill Korotaev
2006-02-06  9:19           ` Eric W. Biederman
2006-02-06 16:37             ` Dave Hansen
2006-02-06 18:37               ` Eric W. Biederman
2006-02-06 19:32                 ` Kirill Korotaev
2006-02-06 22:40                 ` Cedric Le Goater
2006-02-07  1:57                   ` Eric W. Biederman
2006-02-08 21:54                 ` swsusp done by migration (was Re: [RFC][PATCH 1/5] Virtualization/containers: startup) Pavel Machek
2006-02-09 18:20                   ` Eric W. Biederman
2006-02-10  0:21                     ` Kyle Moffett
2006-02-10  4:31                       ` Sam Vilain
2006-02-10  6:23                         ` [Devel] " Vasily Averin
2006-02-11  2:38                           ` Sam Vilain
2006-02-11 17:29                             ` Vasily Averin
2006-02-12 23:29                               ` Sam Vilain
2006-02-10  8:29                         ` Kyle Moffett
2006-02-10  5:40                 ` [RFC][PATCH 1/5] Virtualization/containers: startup Nigel Cunningham
2006-02-10  6:01                   ` Eric W. Biederman
2006-02-06 10:16   ` Jes Sorensen
2006-02-05 20:13 ` Andi Kleen
2006-02-06  9:04   ` Kirill Korotaev
2006-02-06  0:56 ` Benjamin Herrenschmidt
2006-02-06  9:03   ` [Devel] " Kirill Korotaev
2006-02-06  8:31 ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43E61448.7010704@sw.ru \
    --to=dev@sw.ru \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arjan@infradead.org \
    --cc=clg@fr.ibm.com \
    --cc=dev@openvz.org \
    --cc=devel@openvz.org \
    --cc=frankeh@watson.ibm.com \
    --cc=greg@kroah.com \
    --cc=haveblue@us.ibm.com \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riel@redhat.com \
    --cc=saw@sawoct.com \
    --cc=serue@us.ibm.com \
    --cc=torvalds@osdl.org \
    --cc=xemul@sw.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox