From: Dave Hansen <haveblue@us.ibm.com>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Kirill Korotaev <dev@sw.ru>, 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: Fri, 03 Feb 2006 10:34:01 -0800 [thread overview]
Message-ID: <1138991641.6189.37.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.64.0602030939250.4630@g5.osdl.org>
On Fri, 2006-02-03 at 09:49 -0800, Linus Torvalds wrote:
> One thing I don't particularly like is some of the naming. To me "vps"
> doesn't sound particularly generic or logical. I realize that it probably
> makes perfect sense to you (and I assume it just means "virtual private
> servers"), but especially if you see patches 1-3 to really be independent
> of any "actual" virtualization code that is totally generic, I'd actually
> prefer a less specialized name.
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.
"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"?
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?
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?
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.
How does the attached patch look?
-- Dave
memhotplug-dave/include/linux/container.h | 40 +++++++++++++++++++++++++
memhotplug-dave/include/linux/init_task.h | 2 +
memhotplug-dave/include/linux/sched.h | 4 ++
memhotplug-dave/init/main.c | 8 +++++
memhotplug-dave/kernel/exit.c | 2 +
memhotplug-dave/kernel/fork.c | 2 +
6 files changed, 58 insertions(+)
diff -puN include/linux/container.h~container-base include/linux/container.h
--- memhotplug/include/linux/container.h~container-base 2006-02-03 10:21:36.000000000 -0800
+++ memhotplug-dave/include/linux/container.h 2006-02-03 10:21:36.000000000 -0800
@@ -0,0 +1,40 @@
+#ifndef __LINUX_VPS_INFO_H_
+#define __LINUX_VPS_INFO_H_
+
+#include <asm/types.h>
+#include <asm/atomic.h>
+
+struct task_struct;
+
+struct container {
+ u32 id;
+ struct task_struct *init_task;
+ atomic_t refcnt;
+};
+
+extern struct container root_container;
+
+static inline container_t get_container(container_t container)
+{
+ atomic_inc(&container->refcnt);
+ return container;
+}
+
+static inline void put_container(container_t container)
+{
+ atomic_dec(&container->refcnt);
+}
+
+#include <linux/sched.h>
+#include <asm/current.h>
+
+static inline container_t set_current_container(container_t container)
+{
+ container_t ret;
+
+ ret = current->owning_container;
+ current->owning_container = container;
+ return ret;
+}
+
+#endif
diff -puN include/linux/init_task.h~container-base include/linux/init_task.h
--- memhotplug/include/linux/init_task.h~container-base 2006-02-03 10:21:36.000000000 -0800
+++ memhotplug-dave/include/linux/init_task.h 2006-02-03 10:23:49.000000000 -0800
@@ -3,6 +3,7 @@
#include <linux/file.h>
#include <linux/rcupdate.h>
+#include <linux/container.h>
#define INIT_FDTABLE \
{ \
@@ -121,6 +122,7 @@ extern struct group_info init_groups;
.journal_info = NULL, \
.cpu_timers = INIT_CPU_TIMERS(tsk.cpu_timers), \
.fs_excl = ATOMIC_INIT(0), \
+ .owning_container = &root_container, \
}
diff -puN include/linux/sched.h~container-base include/linux/sched.h
--- memhotplug/include/linux/sched.h~container-base 2006-02-03 10:21:36.000000000 -0800
+++ memhotplug-dave/include/linux/sched.h 2006-02-03 10:21:36.000000000 -0800
@@ -687,6 +687,7 @@ static inline void prefetch_stack(struct
struct audit_context; /* See audit.c */
struct mempolicy;
+struct container;
struct task_struct {
volatile long state; /* -1 unrunnable, 0 runnable, >0 stopped */
@@ -844,6 +845,7 @@ struct task_struct {
struct backing_dev_info *backing_dev_info;
struct io_context *io_context;
+ struct container *owning_container;
unsigned long ptrace_message;
siginfo_t *last_siginfo; /* For ptrace use. */
@@ -874,6 +876,8 @@ struct task_struct {
struct rcu_head rcu;
};
+#define current_container() (current->owning_container)
+
static inline pid_t process_group(struct task_struct *tsk)
{
return tsk->signal->pgrp;
diff -puN init/main.c~container-base init/main.c
--- memhotplug/init/main.c~container-base 2006-02-03 10:21:36.000000000 -0800
+++ memhotplug-dave/init/main.c 2006-02-03 10:21:36.000000000 -0800
@@ -47,6 +47,7 @@
#include <linux/rmap.h>
#include <linux/mempolicy.h>
#include <linux/key.h>
+#include <linux/container.h>
#include <asm/io.h>
#include <asm/bugs.h>
@@ -434,6 +435,13 @@ void __init parse_early_param(void)
done = 1;
}
+struct container root_container = {
+ .id = 0,
+ .init_task = &init_task,
+ .refcnt = ATOMIC_INIT(1),
+};
+
+EXPORT_SYMBOL(root_container);
/*
* Activate the first processor.
*/
diff -puN kernel/exit.c~container-base kernel/exit.c
--- memhotplug/kernel/exit.c~container-base 2006-02-03 10:21:36.000000000 -0800
+++ memhotplug-dave/kernel/exit.c 2006-02-03 10:21:36.000000000 -0800
@@ -31,6 +31,7 @@
#include <linux/signal.h>
#include <linux/cn_proc.h>
#include <linux/mutex.h>
+#include <linux/container.h>
#include <asm/uaccess.h>
#include <asm/unistd.h>
@@ -107,6 +108,7 @@ repeat:
spin_unlock(&p->proc_lock);
proc_pid_flush(proc_dentry);
release_thread(p);
+ put_container(p->owning_container);
put_task_struct(p);
p = leader;
diff -puN kernel/fork.c~container-base kernel/fork.c
--- memhotplug/kernel/fork.c~container-base 2006-02-03 10:21:36.000000000 -0800
+++ memhotplug-dave/kernel/fork.c 2006-02-03 10:21:36.000000000 -0800
@@ -44,6 +44,7 @@
#include <linux/rmap.h>
#include <linux/acct.h>
#include <linux/cn_proc.h>
+#include <linux/container.h>
#include <asm/pgtable.h>
#include <asm/pgalloc.h>
@@ -1132,6 +1133,7 @@ static task_t *copy_process(unsigned lon
p->ioprio = current->ioprio;
SET_LINKS(p);
+ get_container(p->owning_container);
if (unlikely(p->ptrace & PT_PTRACED))
__ptrace_link(p, current->parent);
_
next prev parent reply other threads:[~2006-02-03 18:34 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-03 16:58 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 [this message]
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
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=1138991641.6189.37.camel@localhost.localdomain \
--to=haveblue@us.ibm.com \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arjan@infradead.org \
--cc=clg@fr.ibm.com \
--cc=dev@openvz.org \
--cc=dev@sw.ru \
--cc=devel@openvz.org \
--cc=frankeh@watson.ibm.com \
--cc=greg@kroah.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
Powered by JetHome