lwn.net의 PID Namespace 관련 글 하나를 번역해보았다.
Namespace는 커널 2.6.24버전부터 도입된 것으로, 일종의 독립적인 PID 공간이라고 볼 수 있다. Namespace들 간에 부모-자식 관계가 있으며, 각 Namespace별로 PID가 따로 관리되기 때문에 동일한 PID를 Namespace별로 사용할 수 있게 된다.
다음은 글의 원문이다.
pid namespace는 시스템 상의 태스크의 특정 집합의 "View"이다. 그들은 파일시스템의 namespace와 유사한 방법으로 동작한다. 파일(혹은 프로세스)은 다양한 namespace에서 접근될 수 있다. 그러나 파일(혹은 프로세스)은 각 namespace에서 다른 이름을 가져야 할 것이다. 파일시스템에서, 한 namespace에서 이름이 /etc/passwd가 될 수 있다. 하지만 다른 namespace에서는 /chroot/etc/passwd가 되어야 한다.
Namespace는 커널 2.6.24버전부터 도입된 것으로, 일종의 독립적인 PID 공간이라고 볼 수 있다. Namespace들 간에 부모-자식 관계가 있으며, 각 Namespace별로 PID가 따로 관리되기 때문에 동일한 PID를 Namespace별로 사용할 수 있게 된다.
다음은 글의 원문이다.
A pid namespace is a "view" of a particular set of tasks on the system. They work in a similar way to filesystem namespaces. A file (or a process) can be accessed in multiple namespaces, but it may have a different name in each. In a filesystem, this name might be /etc/passwd in one namespace, but /chroot/etc/passwd in another.
For processes, a process may have pid 1234 in one namespace, but be pid 1 in another. This allows new pid namespaces to have basically arbitrary pids, and not have to worry about what pids exist in other namespaces. This is essential for checkpoint/restart where a restarted process's pid might collide with an existing process on the system's pid.In this particular implementation, pid namespaces have a parent-child relationship, just like processes. A process in a pid namespace may see all of the processes in the same namespace, as well as all of the processes in all of the namespaces which are children of its namespace. Processes may not, however, see others which are in their parent's namespace, but not in their own. The same goes for sibling namespaces.
The know issue to be solved in the nearest future is signal handling in the namespace boundary. That is, currently the namespace's init is treated like an ordinary task that can be killed from within an namespace. Ideally, the signal handling by the namespace's init should have two sides: when signaling the init from its namespace, the init should look like a real init task, i.e. receive only those signals, that is explicitly wants to; when signaling the init from one of the parent namespaces, init should look like an ordinary task, i.e. receive any signal, only taking the general permissions into account.
The pid namespace was developed by Pavel Emlyanov and Sukadev Bhattiprolu and we eventually came to almost the same implementation, which differed in some details. This set is based on Pavel's patches, but it includes comments and patches that from Sukadev.
Many thanks to Oleg, who reviewed the patches, pointed out many BUGs and made valuable advises on how to make this set cleaner.
pid namespace는 시스템 상의 태스크의 특정 집합의 "View"이다. 그들은 파일시스템의 namespace와 유사한 방법으로 동작한다. 파일(혹은 프로세스)은 다양한 namespace에서 접근될 수 있다. 그러나 파일(혹은 프로세스)은 각 namespace에서 다른 이름을 가져야 할 것이다. 파일시스템에서, 한 namespace에서 이름이 /etc/passwd가 될 수 있다. 하지만 다른 namespace에서는 /chroot/etc/passwd가 되어야 한다.
원문주소 : http://lwn.net/Articles/245104/프로세스들을 위해서, 프로세스는 한 namespace에서 pid 1234를 가질 수 있지만 다른 곳에서는 pid 1이 될 수 있다. 이는 다른 namespace에 어떤 pid가 있는지 고려하지 않고 새로운 pid namespace가 기본적으로 임의의 pid들을 가질 수 있도록 해준다. 이는 재 시작된 프로세스의 pid가 시스템의 pid상에서 존재하는 프로세스와 충돌할 때,
checkpoint/restart를 위해서 필수적이다.
특정 구현에서, pid namespace는 마치 프로세스처럼 부모-자식 관계를 갖는다. pid namespace 내의 프로세스는 같은 namespace안의 모든 프로세스 뿐만 아니라 그 namespace의 자녀 관계인 namespace들 안의 모든 프로세스들도 볼 수 있을 것이다. 그러나 프로세스는 그들의 부모 namespace의 프로세스들을 볼 수 없을 것이고, 사촌관계에 있는 namespace의 프로세스들도 볼 수 없을 것이다.곧 해결될 이슈는 namespace 경계에서 시그널 처리이다. 이것은 현재 namespace의 init이 namespace에서 kill될 수 있는 일반적인 태스크처럼 다루어지기 때문이다. 이상적으로, namespace의 init에 의한 시그널 처리는 두 가지 측면을 가져야만 한다. : 그것의 namespace로부터 init에 시그널이 도착했을 경우, init은 실제 init 태스크처럼 보인다. 즉 시그널을 받았을 때, 그것은 확실히 받길 원하는 것이어야 한다. 부모 namespace의 하나로부터 init이 시그널을 받았을 때, init은 일반 태스크처럼 보여야 한다. 즉 어떤 시그널을 받던지, 일반적인 권한이 고려되어야 한다.pid namespace는 Pavel Emlyanov와 Sukadev Bhattiprolu에 의해서 개발되었다. 우리는 거의 같은 사양으로 구현하기로 결정하였고, 몇몇 세부사항만이 다를 뿐이다. 이는 Pavel의 패치에 기초하였으나, 그것은 Sukadev로부터의 패치와 코멘트를 포함하고 있다.
'Tips > Kernel development' 카테고리의 다른 글
| VFS : Virtual File System - Introduction (0) | 2012.09.30 |
|---|---|
| Linux Kernel : 커널이란 (0) | 2012.01.31 |
