linux-kernel - Re: [PATCH 2.6.25-rc2 3/9] config: Improve init/Kconfig help descriptions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 21 Feb 2008 10:10:44 +1100
From:	Nick Andrew <nick@...k-andrew.net>
To:	serge@...lyn.com
Cc:	Randy Dunlap <randy.dunlap@...cle.com>,
	Pavel Emelyanov <xemul@...nvz.org>,
	linux-kernel@...r.kernel.org, Serge Hallyn <serue@...ibm.com>
Subject: Re: [PATCH 2.6.25-rc2 3/9] config: Improve init/Kconfig help	descriptions - namespaces

On Wed, Feb 20, 2008 at 10:50:34AM -0600, serge@...lyn.com wrote:
> thanks for all this work.
> 
> Perhaps it would be better to have a Documentation/Namespaces/PID file
> describing these semantics, and have the description read something
> briefer like
> 
> 	  Pid namespaces provide filtered views of processes and their
> 	  process ids.  This features is used to implement containers.
> 	  Please see Documentation/Namespaces/PID for details.
> 
> But in any case with Pavel's comments this looks very good.

I'm sure you're right, but my goal is to improve all the Kconfig help
messages (clarity, accuracy, consistency) and so at this time I want
to limit myself to changes to the help descriptions.

If somebody will add documentation for this or any other subsystem
I will gladly refer to it but in the meantime I'm sure we can come up
with a wording which everybody can agree with.

The point of view I'm coming from is that of a non-kernel-developer
who has to make a choice about some feature of the kernel which they
don't understand. When I'm configuring a kernel I appreciate a bit more
detail in the help text.  I want to provide enough information to help
the user make a rational choice, or give them some idea about what they
are agreeing to put into their kernel. If they still don't understand,
there will be a suggested safe answer.

I'll see if I can make it briefer, if there's any fat which can be
trimmed away.

Current wording:

@@ -446,12 +486,20 @@ 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.
+         Process IDs will be unique only within each PID namespace.
+         This allows multiple processes to have the same PID
+         so long as they are in different PID namespaces. Furthermore,
+         each process will have a distinct PID in each namespace
+         the process is in.
+
+         This is used by container systems (i.e. vservers).
+         Tasks in the container are placed in the PID namespace
+         corresponding to the container, and cannot see or
+         affect processes in any parent PID namespaces.
+
+         If unsure, say N.

 config BLK_DEV_INITRD
        bool "Initial RAM filesystem and RAM disk (initramfs/initrd) support"


Nick.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/