Rewrite the help descriptions for clarity, accuracy and consistency.
Kernel config options affected:
- NAMESPACES
- UTS_NS
- IPC_NS
- USER_NS
- PID_NS
Signed-off-by: Nick Andrew <[email protected]>
---
Try #3.
--- a/init/Kconfig 2008-02-20 09:34:48.000000000 +1100
+++ b/init/Kconfig 2008-02-22 09:01:09.000000000 +1100
@@ -414,31 +414,71 @@ config NAMESPACES
bool "Namespaces support" if EMBEDDED
default !EMBEDDED
help
- Provides the way to make tasks work with different objects using
- the same id. For example same IPC id may refer to different objects
- or same user id or pid may refer to different tasks when used in
- different namespaces.
+ Select various namespace options.
+
+ Namespaces allow different kernel objects (such as processes
+ or sockets) to have the same ID in different namespaces.
+ Identifiers like process IDs, which historically were globally
+ unique, will now be unique only within each PID namespace.
+ Each task can refer only to PIDs within the same namespace
+ as the task itself.
+
+ Namespaces are used by container systems (i.e. vservers)
+ to provide isolation between the containers.
+
+ This option does not affect any kernel code directly; it merely
+ allows you to select namespace options below.
+
+ Answer Y if you will be using a container system, and you
+ will probably want to enable all the namespace options
+ below.
config UTS_NS
bool "UTS namespace"
depends on NAMESPACES
help
- In this namespace tasks see different info provided with the
- uname() system call
+ Enable support for multiple UTS system attributes.
+
+ Each UTS namespace provides an individual view of the
+ information returned by the uname() system call including
+ hostname, kernel version and domain name.
+
+ This is used by container systems (e.g. vservers) so that
+ each container has its own hostname and other attributes.
+ Tasks in the container are placed in the UTS namespace
+ corresponding to the container.
+
+ Answer Y if you will be using a container system.
config IPC_NS
bool "IPC namespace"
depends on NAMESPACES && SYSVIPC
help
- In this namespace tasks work with IPC ids which correspond to
- different IPC objects in different namespaces
+ Enable support for namespace-specific IPC IDs.
+
+ IPC IDs will be unique only within each IPC namespace.
+
+ This is used by container systems (e.g. vservers).
+ Tasks in the container are placed in the IPC namespace
+ corresponding to the container.
+
+ Answer Y if you will be using a container system.
config USER_NS
bool "User namespace (EXPERIMENTAL)"
depends on NAMESPACES && EXPERIMENTAL
help
- This allows containers, i.e. vservers, to use user namespaces
- to provide different user info for different servers.
+ Enable experimental support for user namespaces.
+
+ This is a function used by container-based virtualisation systems
+ (e.g. vservers). User namespaces are intended to ensure that
+ processes with the same uid which are in different containers are
+ isolated from each other.
+
+ Currently user namespaces provide separate accounting, while
+ isolation must be provided using SELinux or a custom security
+ module.
+
If unsure, say N.
config PID_NS
@@ -446,12 +486,16 @@ config PID_NS
default n
depends on NAMESPACES && EXPERIMENTAL
help
- Suport process id namespaces. This allows having multiple
- process with the same pid as long as they are in different
- pid namespaces. This is a building block of containers.
+ Enable experimental support for hierarchical process id namespaces.
- Unless you want to work with an experimental feature
- say N here.
+ This is a function used by container-based virtualisation
+ systems (e.g. vservers). Each process will have a distinct
+ Process ID in each PID namespace which the process is in.
+ Processes in the container are placed in the PID namespace
+ corresponding to the container, and cannot see or affect
+ processes in any parent PID namespace.
+
+ If unsure, say N.
config BLK_DEV_INITRD
bool "Initial RAM filesystem and RAM disk (initramfs/initrd) support"
Nick Andrew wrote:
> Rewrite the help descriptions for clarity, accuracy and consistency.
>
> Kernel config options affected:
>
> - NAMESPACES
> - UTS_NS
> - IPC_NS
> - USER_NS
> - PID_NS
>
> Signed-off-by: Nick Andrew <[email protected]>
Acked-by: Pavel Emelyanov <[email protected]>
but I also expect the patch for NET_NS soon :)
> ---
> Try #3.
>
> --- a/init/Kconfig 2008-02-20 09:34:48.000000000 +1100
> +++ b/init/Kconfig 2008-02-22 09:01:09.000000000 +1100
> @@ -414,31 +414,71 @@ config NAMESPACES
> bool "Namespaces support" if EMBEDDED
> default !EMBEDDED
> help
> - Provides the way to make tasks work with different objects using
> - the same id. For example same IPC id may refer to different objects
> - or same user id or pid may refer to different tasks when used in
> - different namespaces.
> + Select various namespace options.
> +
> + Namespaces allow different kernel objects (such as processes
> + or sockets) to have the same ID in different namespaces.
> + Identifiers like process IDs, which historically were globally
> + unique, will now be unique only within each PID namespace.
> + Each task can refer only to PIDs within the same namespace
> + as the task itself.
> +
> + Namespaces are used by container systems (i.e. vservers)
> + to provide isolation between the containers.
> +
> + This option does not affect any kernel code directly; it merely
> + allows you to select namespace options below.
> +
> + Answer Y if you will be using a container system, and you
> + will probably want to enable all the namespace options
> + below.
>
> config UTS_NS
> bool "UTS namespace"
> depends on NAMESPACES
> help
> - In this namespace tasks see different info provided with the
> - uname() system call
> + Enable support for multiple UTS system attributes.
> +
> + Each UTS namespace provides an individual view of the
> + information returned by the uname() system call including
> + hostname, kernel version and domain name.
> +
> + This is used by container systems (e.g. vservers) so that
> + each container has its own hostname and other attributes.
> + Tasks in the container are placed in the UTS namespace
> + corresponding to the container.
> +
> + Answer Y if you will be using a container system.
>
> config IPC_NS
> bool "IPC namespace"
> depends on NAMESPACES && SYSVIPC
> help
> - In this namespace tasks work with IPC ids which correspond to
> - different IPC objects in different namespaces
> + Enable support for namespace-specific IPC IDs.
> +
> + IPC IDs will be unique only within each IPC namespace.
> +
> + This is used by container systems (e.g. vservers).
> + Tasks in the container are placed in the IPC namespace
> + corresponding to the container.
> +
> + Answer Y if you will be using a container system.
>
> config USER_NS
> bool "User namespace (EXPERIMENTAL)"
> depends on NAMESPACES && EXPERIMENTAL
> help
> - This allows containers, i.e. vservers, to use user namespaces
> - to provide different user info for different servers.
> + Enable experimental support for user namespaces.
> +
> + This is a function used by container-based virtualisation systems
> + (e.g. vservers). User namespaces are intended to ensure that
> + processes with the same uid which are in different containers are
> + isolated from each other.
> +
> + Currently user namespaces provide separate accounting, while
> + isolation must be provided using SELinux or a custom security
> + module.
> +
> If unsure, say N.
>
> config PID_NS
> @@ -446,12 +486,16 @@ config PID_NS
> default n
> depends on NAMESPACES && EXPERIMENTAL
> help
> - Suport process id namespaces. This allows having multiple
> - process with the same pid as long as they are in different
> - pid namespaces. This is a building block of containers.
> + Enable experimental support for hierarchical process id namespaces.
>
> - Unless you want to work with an experimental feature
> - say N here.
> + This is a function used by container-based virtualisation
> + systems (e.g. vservers). Each process will have a distinct
> + Process ID in each PID namespace which the process is in.
> + Processes in the container are placed in the PID namespace
> + corresponding to the container, and cannot see or affect
> + processes in any parent PID namespace.
> +
> + If unsure, say N.
>
> config BLK_DEV_INITRD
> bool "Initial RAM filesystem and RAM disk (initramfs/initrd) support"
>
Quoting Nick Andrew ([email protected]):
> Rewrite the help descriptions for clarity, accuracy and consistency.
>
> Kernel config options affected:
>
> - NAMESPACES
> - UTS_NS
> - IPC_NS
> - USER_NS
> - PID_NS
>
> Signed-off-by: Nick Andrew <[email protected]>
> ---
> Try #3.
>
> --- a/init/Kconfig 2008-02-20 09:34:48.000000000 +1100
> +++ b/init/Kconfig 2008-02-22 09:01:09.000000000 +1100
> @@ -414,31 +414,71 @@ config NAMESPACES
> bool "Namespaces support" if EMBEDDED
> default !EMBEDDED
> help
> - Provides the way to make tasks work with different objects using
> - the same id. For example same IPC id may refer to different objects
> - or same user id or pid may refer to different tasks when used in
> - different namespaces.
> + Select various namespace options.
> +
> + Namespaces allow different kernel objects (such as processes
> + or sockets) to have the same ID in different namespaces.
> + Identifiers like process IDs, which historically were globally
> + unique, will now be unique only within each PID namespace.
> + Each task can refer only to PIDs within the same namespace
> + as the task itself.
> +
> + Namespaces are used by container systems (i.e. vservers)
> + to provide isolation between the containers.
> +
> + This option does not affect any kernel code directly; it merely
> + allows you to select namespace options below.
> +
> + Answer Y if you will be using a container system, and you
> + will probably want to enable all the namespace options
> + below.
>
> config UTS_NS
> bool "UTS namespace"
> depends on NAMESPACES
> help
> - In this namespace tasks see different info provided with the
> - uname() system call
> + Enable support for multiple UTS system attributes.
> +
> + Each UTS namespace provides an individual view of the
> + information returned by the uname() system call including
> + hostname, kernel version and domain name.
> +
> + This is used by container systems (e.g. vservers) so that
> + each container has its own hostname and other attributes.
> + Tasks in the container are placed in the UTS namespace
> + corresponding to the container.
Hi Nick,
this paragraph reads a little weird... really what happens is that
each forked task is in the same UTS namespace as its parent, unless
it was cloned with CLONE_NEWUTS or has done unshare(CLONE_NEWUTS),
in which case it receives a copy.
> +
> + Answer Y if you will be using a container system.
>
> config IPC_NS
> bool "IPC namespace"
> depends on NAMESPACES && SYSVIPC
> help
> - In this namespace tasks work with IPC ids which correspond to
> - different IPC objects in different namespaces
> + Enable support for namespace-specific IPC IDs.
> +
> + IPC IDs will be unique only within each IPC namespace.
> +
> + This is used by container systems (e.g. vservers).
> + Tasks in the container are placed in the IPC namespace
> + corresponding to the container.
Same as with UTS, except that upon CLONE_NEWIPC the task receives a
blank new ipc namespace, not a copy of the original.
> + Answer Y if you will be using a container system.
>
> config USER_NS
> bool "User namespace (EXPERIMENTAL)"
> depends on NAMESPACES && EXPERIMENTAL
> help
> - This allows containers, i.e. vservers, to use user namespaces
> - to provide different user info for different servers.
> + Enable experimental support for user namespaces.
> +
> + This is a function used by container-based virtualisation systems
> + (e.g. vservers). User namespaces are intended to ensure that
> + processes with the same uid which are in different containers are
> + isolated from each other.
> +
> + Currently user namespaces provide separate accounting, while
> + isolation must be provided using SELinux or a custom security
> + module.
> +
> If unsure, say N.
>
> config PID_NS
> @@ -446,12 +486,16 @@ config PID_NS
> default n
> depends on NAMESPACES && EXPERIMENTAL
> help
> - Suport process id namespaces. This allows having multiple
> - process with the same pid as long as they are in different
> - pid namespaces. This is a building block of containers.
> + Enable experimental support for hierarchical process id namespaces.
>
> - Unless you want to work with an experimental feature
> - say N here.
> + This is a function used by container-based virtualisation
> + systems (e.g. vservers). Each process will have a distinct
> + Process ID in each PID namespace which the process is in.
> + Processes in the container are placed in the PID namespace
> + corresponding to the container, and cannot see or affect
> + processes in any parent PID namespace.
A cloned process inherits the pid namespace hierarchy from its
parent. If it was cloned with CLONE_NEWPID, the hierarchy is
topped with one additional newly created pid namespace. This
is the only pid namespace in which the new process will be able
to see processes, while it will be visible in all namespaces in
its pidns hierarchy.
A pid namespace cannot be unshared.
> +
> + If unsure, say N.
>
> config BLK_DEV_INITRD
> bool "Initial RAM filesystem and RAM disk (initramfs/initrd) support"
On Fri, Feb 22, 2008 at 04:14:12PM -0600, Serge E. Hallyn wrote:
> Quoting Nick Andrew ([email protected]):
> > config UTS_NS
> > bool "UTS namespace"
> > depends on NAMESPACES
> > help
> > - In this namespace tasks see different info provided with the
> > - uname() system call
> > + Enable support for multiple UTS system attributes.
> > +
> > + Each UTS namespace provides an individual view of the
> > + information returned by the uname() system call including
> > + hostname, kernel version and domain name.
> > +
> > + This is used by container systems (e.g. vservers) so that
> > + each container has its own hostname and other attributes.
> > + Tasks in the container are placed in the UTS namespace
> > + corresponding to the container.
>
> this paragraph reads a little weird... really what happens is that
> each forked task is in the same UTS namespace as its parent, unless
> it was cloned with CLONE_NEWUTS or has done unshare(CLONE_NEWUTS),
> in which case it receives a copy.
You mean only the third paragraph, right? I hope the other two are
accurate.
I'm trying to describe how the feature is used by container systems
and my description is obviously inaccurate. There are subtle semantic
differences between the way the different namespaces work, which you've
pointed out. I think mentioning CLONE_NEWUTS or other flags is too
technical for help descriptions.
For UTS_NS and IPC_NS I think I could remove that paragraph because
the end user hint "Answer Y if you will be using a container system"
remains. For USER_NS and PID_NS however, these features are tagged
EXPERIMENTAL so the hint is "If unsure, say N" and I think I need
to at least mention the use in container systems or find some better
clarifying description which doesn't get too technical.
> > + This is used by container systems (e.g. vservers).
> > + Tasks in the container are placed in the IPC namespace
> > + corresponding to the container.
>
> Same as with UTS, except that upon CLONE_NEWIPC the task receives a
> blank new ipc namespace, not a copy of the original.
Per above my response is to remove the paragraph.
> > config PID_NS
> > [...]
> > default n
> > depends on NAMESPACES && EXPERIMENTAL
> > help
> > - Suport process id namespaces. This allows having multiple
> > - process with the same pid as long as they are in different
> > - pid namespaces. This is a building block of containers.
> > + Enable experimental support for hierarchical process id namespaces.
> >
> > - Unless you want to work with an experimental feature
> > - say N here.
> > + This is a function used by container-based virtualisation
> > + systems (e.g. vservers). Each process will have a distinct
> > + Process ID in each PID namespace which the process is in.
> > + Processes in the container are placed in the PID namespace
> > + corresponding to the container, and cannot see or affect
> > + processes in any parent PID namespace.
>
> A cloned process inherits the pid namespace hierarchy from its
> parent. If it was cloned with CLONE_NEWPID, the hierarchy is
> topped with one additional newly created pid namespace. This
> is the only pid namespace in which the new process will be able
> to see processes, while it will be visible in all namespaces in
> its pidns hierarchy.
Yes, I understand that. Would you agree that your problem is with the
wording "Processes in the container are placed in the PID namespace
corresponding to the container"? And that this is the part that needs
to be fixed?
... todo = revisit these descriptions soon, not today though
Nick.
--
PGP Key ID = 0x418487E7 http://www.nick-andrew.net/
PGP Key fingerprint = B3ED 6894 8E49 1770 C24A 67E3 6266 6EB9 4184 87E7
Quoting Nick Andrew ([email protected]):
> On Fri, Feb 22, 2008 at 04:14:12PM -0600, Serge E. Hallyn wrote:
> > Quoting Nick Andrew ([email protected]):
> > > config UTS_NS
> > > bool "UTS namespace"
> > > depends on NAMESPACES
> > > help
> > > - In this namespace tasks see different info provided with the
> > > - uname() system call
> > > + Enable support for multiple UTS system attributes.
> > > +
> > > + Each UTS namespace provides an individual view of the
> > > + information returned by the uname() system call including
> > > + hostname, kernel version and domain name.
> > > +
> > > + This is used by container systems (e.g. vservers) so that
> > > + each container has its own hostname and other attributes.
> > > + Tasks in the container are placed in the UTS namespace
> > > + corresponding to the container.
> >
> > this paragraph reads a little weird... really what happens is that
> > each forked task is in the same UTS namespace as its parent, unless
> > it was cloned with CLONE_NEWUTS or has done unshare(CLONE_NEWUTS),
> > in which case it receives a copy.
>
> You mean only the third paragraph, right? I hope the other two are
> accurate.
>
> I'm trying to describe how the feature is used by container systems
> and my description is obviously inaccurate. There are subtle semantic
> differences between the way the different namespaces work, which you've
> pointed out. I think mentioning CLONE_NEWUTS or other flags is too
> technical for help descriptions.
>
> For UTS_NS and IPC_NS I think I could remove that paragraph because
> the end user hint "Answer Y if you will be using a container system"
> remains. For USER_NS and PID_NS however, these features are tagged
> EXPERIMENTAL so the hint is "If unsure, say N" and I think I need
> to at least mention the use in container systems or find some better
> clarifying description which doesn't get too technical.
>
> > > + This is used by container systems (e.g. vservers).
> > > + Tasks in the container are placed in the IPC namespace
> > > + corresponding to the container.
> >
> > Same as with UTS, except that upon CLONE_NEWIPC the task receives a
> > blank new ipc namespace, not a copy of the original.
>
> Per above my response is to remove the paragraph.
>
> > > config PID_NS
> > > [...]
> > > default n
> > > depends on NAMESPACES && EXPERIMENTAL
> > > help
> > > - Suport process id namespaces. This allows having multiple
> > > - process with the same pid as long as they are in different
> > > - pid namespaces. This is a building block of containers.
> > > + Enable experimental support for hierarchical process id namespaces.
> > >
> > > - Unless you want to work with an experimental feature
> > > - say N here.
> > > + This is a function used by container-based virtualisation
> > > + systems (e.g. vservers). Each process will have a distinct
> > > + Process ID in each PID namespace which the process is in.
> > > + Processes in the container are placed in the PID namespace
> > > + corresponding to the container, and cannot see or affect
> > > + processes in any parent PID namespace.
> >
> > A cloned process inherits the pid namespace hierarchy from its
> > parent. If it was cloned with CLONE_NEWPID, the hierarchy is
> > topped with one additional newly created pid namespace. This
> > is the only pid namespace in which the new process will be able
> > to see processes, while it will be visible in all namespaces in
> > its pidns hierarchy.
>
> Yes, I understand that. Would you agree that your problem is with the
> wording "Processes in the container are placed in the PID namespace
> corresponding to the container"? And that this is the part that needs
> to be fixed?
Yup.
thanks,
-serge
> ... todo = revisit these descriptions soon, not today though
>
> Nick.
> --
> PGP Key ID = 0x418487E7 http://www.nick-andrew.net/
> PGP Key fingerprint = B3ED 6894 8E49 1770 C24A 67E3 6266 6EB9 4184 87E7
Modify the help descriptions of init/Kconfig for clarity, accuracy and consistency.
Kernel config options affected:
- NAMESPACES
- UTS_NS
- IPC_NS
- USER_NS
- PID_NS
Add a brief description of what namespaces are and when you would
want to use them.
For the *_NS options, add a tiny bit of detail about what it is,
and ensure each config option has an answer hint: Y for namespaces
"if you will be using a container system", Y for the *_NS options
except for the two labeled EXPERIMENTAL.
Signed-off-by: Nick Andrew <[email protected]>
---
Try #4
init/Kconfig | 65 +++++++++++++++++++++++++++++++++++++++++++++-------------
1 files changed, 50 insertions(+), 15 deletions(-)
diff --git a/init/Kconfig b/init/Kconfig
index cc7a341..0e6a084 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -487,31 +487,62 @@ config NAMESPACES
bool "Namespaces support" if EMBEDDED
default !EMBEDDED
help
- Provides the way to make tasks work with different objects using
- the same id. For example same IPC id may refer to different objects
- or same user id or pid may refer to different tasks when used in
- different namespaces.
+ Select various namespace options.
+
+ Namespaces allow different kernel objects (such as processes
+ or sockets) to have the same ID in different namespaces.
+ Identifiers like process IDs, which historically were globally
+ unique, will now be unique only within each PID namespace.
+ Each task can refer only to PIDs within the same namespace
+ as the task itself.
+
+ Namespaces are used by container systems (e.g. vservers)
+ to provide isolation between the containers.
+
+ This option does not affect any kernel code directly; it merely
+ allows you to select namespace options below.
+
+ Answer Y if you will be using a container system, and you
+ will probably want to enable all the namespace options
+ below.
config UTS_NS
bool "UTS namespace"
depends on NAMESPACES
help
- In this namespace tasks see different info provided with the
- uname() system call
+ Enable support for multiple UTS system attributes.
+
+ Each UTS namespace provides an individual view of the
+ information returned by the uname() system call including
+ hostname, kernel version and domain name.
+
+ Answer Y if you will be using a container system.
config IPC_NS
bool "IPC namespace"
depends on NAMESPACES && SYSVIPC
help
- In this namespace tasks work with IPC ids which correspond to
- different IPC objects in different namespaces
+ Enable support for namespace-specific IPC IDs.
+
+ IPC IDs will be unique only within each IPC namespace.
+
+ Answer Y if you will be using a container system.
config USER_NS
bool "User namespace (EXPERIMENTAL)"
depends on NAMESPACES && EXPERIMENTAL
help
- This allows containers, i.e. vservers, to use user namespaces
- to provide different user info for different servers.
+ Enable experimental support for user namespaces.
+
+ This is a function used by container-based virtualisation systems
+ (e.g. vservers). User namespaces are intended to ensure that
+ processes with the same uid which are in different containers are
+ isolated from each other.
+
+ Currently user namespaces provide separate accounting, while
+ isolation must be provided using SELinux or a custom security
+ module.
+
If unsure, say N.
config PID_NS
@@ -519,12 +550,16 @@ config PID_NS
default n
depends on NAMESPACES && EXPERIMENTAL
help
- Suport process id namespaces. This allows having multiple
- process with the same pid as long as they are in different
- pid namespaces. This is a building block of containers.
+ Enable experimental support for hierarchical process id namespaces.
+
+ This is a function used by container-based virtualisation
+ systems (e.g. vservers). Each process will have a distinct
+ Process ID in each PID namespace which the process is in.
+ A process can "see" other processes in the same PID namespace
+ and child PID namespaces, but cannot see processes in parent
+ PID namespaces.
- Unless you want to work with an experimental feature
- say N here.
+ If unsure, say N.
config BLK_DEV_INITRD
bool "Initial RAM filesystem and RAM disk (initramfs/initrd) support"
Quoting Nick Andrew ([email protected]):
> Modify the help descriptions of init/Kconfig for clarity, accuracy and consistency.
>
> Kernel config options affected:
>
> - NAMESPACES
> - UTS_NS
> - IPC_NS
> - USER_NS
> - PID_NS
>
> Add a brief description of what namespaces are and when you would
> want to use them.
>
> For the *_NS options, add a tiny bit of detail about what it is,
> and ensure each config option has an answer hint: Y for namespaces
> "if you will be using a container system", Y for the *_NS options
> except for the two labeled EXPERIMENTAL.
>
> Signed-off-by: Nick Andrew <[email protected]>
Thanks, Nick.
Acked-by: Serge Hallyn <[email protected]>
-serge
> ---
> Try #4
>
>
> init/Kconfig | 65 +++++++++++++++++++++++++++++++++++++++++++++-------------
> 1 files changed, 50 insertions(+), 15 deletions(-)
>
>
> diff --git a/init/Kconfig b/init/Kconfig
> index cc7a341..0e6a084 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -487,31 +487,62 @@ config NAMESPACES
> bool "Namespaces support" if EMBEDDED
> default !EMBEDDED
> help
> - Provides the way to make tasks work with different objects using
> - the same id. For example same IPC id may refer to different objects
> - or same user id or pid may refer to different tasks when used in
> - different namespaces.
> + Select various namespace options.
> +
> + Namespaces allow different kernel objects (such as processes
> + or sockets) to have the same ID in different namespaces.
> + Identifiers like process IDs, which historically were globally
> + unique, will now be unique only within each PID namespace.
> + Each task can refer only to PIDs within the same namespace
> + as the task itself.
> +
> + Namespaces are used by container systems (e.g. vservers)
> + to provide isolation between the containers.
> +
> + This option does not affect any kernel code directly; it merely
> + allows you to select namespace options below.
> +
> + Answer Y if you will be using a container system, and you
> + will probably want to enable all the namespace options
> + below.
>
> config UTS_NS
> bool "UTS namespace"
> depends on NAMESPACES
> help
> - In this namespace tasks see different info provided with the
> - uname() system call
> + Enable support for multiple UTS system attributes.
> +
> + Each UTS namespace provides an individual view of the
> + information returned by the uname() system call including
> + hostname, kernel version and domain name.
> +
> + Answer Y if you will be using a container system.
>
> config IPC_NS
> bool "IPC namespace"
> depends on NAMESPACES && SYSVIPC
> help
> - In this namespace tasks work with IPC ids which correspond to
> - different IPC objects in different namespaces
> + Enable support for namespace-specific IPC IDs.
> +
> + IPC IDs will be unique only within each IPC namespace.
> +
> + Answer Y if you will be using a container system.
>
> config USER_NS
> bool "User namespace (EXPERIMENTAL)"
> depends on NAMESPACES && EXPERIMENTAL
> help
> - This allows containers, i.e. vservers, to use user namespaces
> - to provide different user info for different servers.
> + Enable experimental support for user namespaces.
> +
> + This is a function used by container-based virtualisation systems
> + (e.g. vservers). User namespaces are intended to ensure that
> + processes with the same uid which are in different containers are
> + isolated from each other.
> +
> + Currently user namespaces provide separate accounting, while
> + isolation must be provided using SELinux or a custom security
> + module.
> +
> If unsure, say N.
>
> config PID_NS
> @@ -519,12 +550,16 @@ config PID_NS
> default n
> depends on NAMESPACES && EXPERIMENTAL
> help
> - Suport process id namespaces. This allows having multiple
> - process with the same pid as long as they are in different
> - pid namespaces. This is a building block of containers.
> + Enable experimental support for hierarchical process id namespaces.
> +
> + This is a function used by container-based virtualisation
> + systems (e.g. vservers). Each process will have a distinct
> + Process ID in each PID namespace which the process is in.
> + A process can "see" other processes in the same PID namespace
> + and child PID namespaces, but cannot see processes in parent
> + PID namespaces.
>
> - Unless you want to work with an experimental feature
> - say N here.
> + If unsure, say N.
>
> config BLK_DEV_INITRD
> bool "Initial RAM filesystem and RAM disk (initramfs/initrd) support"