vpid'ы и namespace (Кто-нибудь уже с этим работал?)

Взгляд изнутри

Модератор: Модераторы разделов

Ответить
Аватара пользователя
nesk
Сообщения: 2268
Статус: Линукссаксовец
ОС: MS Windows XP Home SP3
Контактная информация:

vpid'ы и namespace

Сообщение nesk »

Так получилось, что недавно впервые за три года я заглянул в исходники ядра linux.
Виртуализация на марше.
Обнаружил там vpid и namespace :)
Кто-нить уже с этим работал?
Из userspace этим уже можно управлять? (OpenVZ ?)
Внимание: У меня под рукой нет машины с Linux. Я не использую эту ОС. Ответы я даю либо по памяти, либо мне помогает гугл. Тщательно читайте маны по тем командам и конфигурационным файлам, которые я упоминаю.

0xDEFEC8ED
Спасибо сказали:
Аватара пользователя
PodBot
Сообщения: 13
ОС: GNU/Linux

Re: vpid'ы и namespace

Сообщение PodBot »

nesk писал(а):
13.03.2010 10:49
Так получилось, что недавно впервые за три года я заглянул в исходники ядра linux.
Виртуализация на марше.
Обнаружил там vpid и namespace :)
Кто-нить уже с этим работал?
Из userspace этим уже можно управлять? (OpenVZ ?)

Сейчас существует штука, называемая Linux Containers
http://www.ibm.com/developerworks/linux/li...lxc-containers/ - обзор
http://lxc.sourceforge.net/ - сам проект

http://lwn.net/Articles/259217/
+ Небольшая компиляция про PID namespace
;
struct rcu_head rcu;
+ int level;
+ struct upid numbers[1];
};

extern struct pid init_struct_pid;

Each namespace has a parent and is characterized by its "level". Level is the number of the namespace generation. E.g. init namespace has level 0, after cloning new one it will have level 1, the next one - 2 and so on and so forth. This level is not explicitly limited.

True hierarchy must have some way to find each namespace's children, but it is not used in the patches, so this ability is not added (yet).

include/linux/pid_namespace.h | 2 ++
kernel/pid.c | 3 ++-
2 files changed, 4 insertions(+), 1 deletion(-)

--- ./include/linux/pid_namespace.h.ve5 2007-08-09 17:54:49.000000000 +0400
+++ ./include/linux/pid_namespace.h 2007-08-10 12:39:22.000000000 +0400
@@ -21,6 +21,8 @@ struct pid_namespace {
int last_pid;
struct task_struct *child_reaper;
struct kmem_cache *pid_cachep;
+ int level;
+ struct pid_namespace *parent;
};

extern struct pid_namespace init_pid_ns;
--- ./kernel/pid.c.ve5 2007-08-09 17:54:51.000000000 +0400
+++ ./kernel/pid.c 2007-08-10 12:39:57.000000000 +0400
@@ -67,7 +67,8 @@ struct pid_namespace init_pid_ns = {
[ 0 ... PIDMAP_ENTRIES-1] = { ATOMIC_INIT(BITS_PER_PAGE), NULL }
},
.last_pid = 0,
- .child_reaper = &init_task
+ .level = 0,
+ .child_reaper = &init_task,
};

=========================
(from 2.6.29-rc7 sources)
enum pid_type
{
PIDTYPE_PID,
PIDTYPE_PGID,
PIDTYPE_SID,
PIDTYPE_MAX
};

/*
* What is struct pid?
*
* A struct pid is the kernel's internal notion of a process identifier.
* It refers to individual tasks, process groups, and sessions. While
* there are processes attached to it the struct pid lives in a hash
* table, so it and then the processes that it refers to can be found
* quickly from the numeric pid value. The attached processes may be
* quickly accessed by following pointers from struct pid.
*
* Storing pid_t values in the kernel and refering to them later has a
* problem. The process originally with that pid may have exited and the
* pid allocator wrapped, and another process could have come along
* and been assigned that pid.
*
* Referring to user space processes by holding a reference to struct
* task_struct has a problem. When the user space process exits
* the now useless task_struct is still kept. A task_struct plus a
* stack consumes around 10K of low kernel memory. More precisely
* this is THREAD_SIZE + sizeof(struct task_struct). By comparison
* a struct pid is about 64 bytes.
*
* Holding a reference to struct pid solves both of these problems.
* It is small so holding a reference does not consume a lot of
* resources, and since a new struct pid is allocated when the numeric pid
* value is reused (when pids wrap around) we don't mistakenly refer to new
* processes.
*/


/*
* struct upid is used to get the id of the struct pid, as it is
* seen in particular namespace. Later the struct pid is found with
* find_pid_ns() using the int nr and struct pid_namespace *ns.
*/

struct upid {
/* Try to keep pid_chain in the same cacheline as nr for find_vpid */
int nr;
struct pid_namespace *ns;
struct hlist_node pid_chain;
};

struct pid
{
atomic_t count;
unsigned int level;
/* lists of tasks that use this pid */
struct hlist_head tasks[PIDTYPE_MAX];
struct rcu_head rcu;
struct upid numbers[1];
};

extern struct pid init_struct_pid;

struct pid_link
{
struct hlist_node node;
struct pid *pid;
};
]


Have fun! ;)
Спасибо сказали:
Ответить