mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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);
 
_



  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