On Thu, 2007-11-01 at 07:56 -0700, Ulrich Drepper wrote:Yeah, we definitely realize that this inhibits things that were perfectly fine before. As Eric mentioned in his reply to your message last year, the primary goal here is isolation. We'd eventually like to be able to pick a container up and move it to another system. That's going to be awfully hard if the container is sharing a resource with a part of the system which is not moving. Pid namespaces (along with the others) give us the isolation to keep these interactions from happening except in a controlled manner, breaking the ties that might bind it to one particular system. Think of how many user-visible apis deal with files and filenames. However, there can certainly be files that are unavailable to certain processes based on their membership in a particular filesystem namespaces. In fact, we use chroot() to try and _make_ certain files unavailable. -- Dave -
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Srivatsa Vaddagiri | containers (was Re: -mm merge plans for 2.6.23) |
| Benjamin Herrenschmidt | Re: [linux-pm] [PATCH] Remove process freezer from suspend to RAM pathway |
git: | |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Patrick McHardy | Re: [GIT]: Networking |
| Gerrit Renker | [PATCH 6/7] [CCID-2/3]: Fix sparse warnings |
