Skip to contentSkip to conversation

Namespaces submenu

PATCH In review Dave Hansen 4 participants 7 messages Jun 5, 2009 – Jun 8, 2009 1 message not in the archive

lore
Share & tools
lore
#0 lore raw

PATCH 1/4 Namespaces submenu

Let's not steal too much space in the 'General Setup' menu. Take a cue from the cgroups code and create a submenu.

This can go upstream now.

---

 linux-2.6.git-dave/init/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
init/Kconfig renamed from init/Kconfig~namespaces-submenu +1 -1
diff -puN init/Kconfig~namespaces-submenu init/Kconfig
@@ -658,7 +658,7 @@ config RELAY
 
 	  If unsure, say N.
 
-config NAMESPACES
+menuconfig NAMESPACES
 	bool "Namespaces support" if EMBEDDED
 	default !EMBEDDED
 	help

_

#1 lore raw

PATCH 2/4 Move checkpoint closer to namespaces

These are pretty intimately related, so let's make them closer to each other in Kconfig. This shoudl be pushed up into the patch that creates CONFIG_CHECKPOINT in the first place.

---

 linux-2.6.git-dave/init/Kconfig |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
init/Kconfig renamed from init/Kconfig~move-cr-close-to-namespaces +2 -2
diff -puN init/Kconfig~move-cr-close-to-namespaces init/Kconfig
@@ -709,6 +709,8 @@ config NET_NS
 	  Allow user space to create what appear to be multiple instances
 	  of the network stack.
 
+source "checkpoint/Kconfig"
+
 config BLK_DEV_INITRD
 	bool "Initial RAM filesystem and RAM disk (initramfs/initrd) support"
 	depends on BROKEN || !FRV
@@ -1042,8 +1044,6 @@ config SLOW_WORK
 
 	  See Documentation/slow-work.txt.
 
-source "checkpoint/Kconfig"
-
 endmenu		# General setup
 
 config HAVE_GENERIC_DMA_COHERENT

_

#2 lore raw

PATCH 3/4 kill 'Enable' in c/r config option

In reply to Dave Hansen

We don't neeeed to say 'Enable'. That's what Kconfig does for everything. :)

---

 linux-2.6.git-dave/checkpoint/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
checkpoint/Kconfig renamed from checkpoint/Kconfig~kill-Enabled +1 -1
diff -puN checkpoint/Kconfig~kill-Enabled checkpoint/Kconfig
@@ -7,7 +7,7 @@ config DEFERQUEUE
 	default n
 
 config CHECKPOINT
-	bool "Enable checkpoint/restart (EXPERIMENTAL)"
+	bool "Checkpoint/restart (EXPERIMENTAL)"
 	depends on CHECKPOINT_SUPPORT && EXPERIMENTAL
 	select DEFERQUEUE
 	help

_

#3 lore raw

PATCH 4/4 Conditionally force on namespaces

In reply to Dave Hansen

This should work around the compile issues that Nathan pointed out yesterday. It's too bad that 'select' is such a blunt object. We could surely use a soft select or something. But this hacks around it a bit.

Create a separate "*_NS_DEP" Kconfig option for the dependencies for each namespace. Make the real config option and the c/r 'select' bot dependent on the new common one.

This should at least keep compile errors from being introduced. Whether this is rude or not is a separate questions. :)

---

 linux-2.6.git-dave/checkpoint/Kconfig |    6 ++++++
 linux-2.6.git-dave/init/Kconfig       |   30 +++++++++++++++++++++++++-----
 2 files changed, 31 insertions(+), 5 deletions(-)
init/Kconfig renamed from init/Kconfig~force-on-namespaces +25 -5
diff -puN init/Kconfig~force-on-namespaces init/Kconfig
@@ -667,32 +667,48 @@ menuconfig NAMESPACES
 	  or same user id or pid may refer to different tasks when used in
 	  different namespaces.
 
+config UTS_NS_DEP
+	def_bool y
+	depends on NAMESPACES
+
 config UTS_NS
 	bool "UTS namespace"
-	depends on NAMESPACES
+	depends on UTS_NS_DEP
 	help
 	  In this namespace tasks see different info provided with the
 	  uname() system call
 
+config IPC_NS_DEP
+	def_bool y
+	depends on NAMESPACES && (SYSVIPC || POSIX_MQUEUE)
+
 config IPC_NS
 	bool "IPC namespace"
-	depends on NAMESPACES && (SYSVIPC || POSIX_MQUEUE)
+	depends on IPC_NS_DEP
 	help
 	  In this namespace tasks work with IPC ids which correspond to
 	  different IPC objects in different namespaces.
 
+config USER_NS_DEP
+	def_bool y
+	depends on NAMESPACES && EXPERIMENTAL
+
 config USER_NS
 	bool "User namespace (EXPERIMENTAL)"
-	depends on NAMESPACES && EXPERIMENTAL
+	depends on USER_NS_DEP
 	help
 	  This allows containers, i.e. vservers, to use user namespaces
 	  to provide different user info for different servers.
 	  If unsure, say N.
 
+config PID_NS_DEP
+	def_bool y
+	depends on NAMESPACES && EXPERIMENTAL
+
 config PID_NS
 	bool "PID Namespaces (EXPERIMENTAL)"
 	default n
-	depends on NAMESPACES && EXPERIMENTAL
+	depends on PID_NS_DEP
 	help
 	  Support process id namespaces.  This allows having multiple
 	  processes with the same pid as long as they are in different
@@ -701,10 +717,14 @@ config PID_NS
 	  Unless you want to work with an experimental feature
 	  say N here.
 
+config NET_NS_DEP
+	def_bool y
+	depends on NAMESPACES && EXPERIMENTAL && NET
+
 config NET_NS
 	bool "Network namespace"
 	default n
-	depends on NAMESPACES && EXPERIMENTAL && NET
+	depends on NET_NS_DEP
 	help
 	  Allow user space to create what appear to be multiple instances
 	  of the network stack.
checkpoint/Kconfig renamed from checkpoint/Kconfig~force-on-namespaces +6 -0
diff -puN checkpoint/Kconfig~force-on-namespaces checkpoint/Kconfig
@@ -10,6 +10,12 @@ config CHECKPOINT
 	bool "Checkpoint/restart (EXPERIMENTAL)"
 	depends on CHECKPOINT_SUPPORT && EXPERIMENTAL
 	select DEFERQUEUE
+	select NAMESPACE
+	select UTS_NS if UTS_NS_DEP
+	select IPC_NS if IPC_NS_DEP
+	select NET_NS if NET_NS_DEP
+	select PID_NS if PID_NS_DEP
+	select USER_NS if USER_NS_DEP
 	help
 	  Application checkpoint/restart is the ability to save the
 	  state of a running application so that it can later resume

_

#4 lore raw

Re: [PATCH 4/4] Conditionally force on namespaces

Quoted 6 lines · Dave Hansen

This should work around the compile issues that Nathan pointed out yesterday. It's too bad that 'select' is such a blunt object. We could surely use a soft select or something. But this hacks around it a bit.

Quoted 8 lines

Create a separate "*_NS_DEP" Kconfig option for the dependencies for each namespace. Make the real config option and the c/r 'select' bot dependent on the new common one.

This should at least keep compile errors from being introduced. Whether this is rude or not is a separate questions. :)

Yeah I'm not sure I'm a fan of this...

While I hate chasing down missing dependencies, maybe CONFIG_CHECKPOINT should just depend on all the namespaces instead of selecting them?

I'd assumed that was Nathan was really asking for, though I could be wrong.

-serge

A message that is not in the archive (sent off-list or not yet received): 20090605193538.GA22848-r/[email protected]

#6 lore raw

Re: [PATCH 4/4] Conditionally force on namespaces

Quoted 16 lines · Serge E. Hallyn
Quoted 6 lines · Dave Hansen

This should work around the compile issues that Nathan pointed out yesterday. It's too bad that 'select' is such a blunt object. We could surely use a soft select or something. But this hacks around it a bit.

Quoted 8 lines

Create a separate "*_NS_DEP" Kconfig option for the dependencies for each namespace. Make the real config option and the c/r 'select' bot dependent on the new common one.

This should at least keep compile errors from being introduced. Whether this is rude or not is a separate questions. :)

Quoted 8 lines

Yeah I'm not sure I'm a fan of this...

While I hate chasing down missing dependencies, maybe CONFIG_CHECKPOINT should just depend on all the namespaces instead of selecting them?

I'd assumed that was Nathan was really asking for, though I could be wrong.

I was mainly interested in preventing build breaks. :)

While Oren's checkpoint implementation is useful with any combination of the *_NS config options, ensuring that the kernel builds and functions correctly with all the permutations looks non-trivial. Making CHECKPOINT depend on all the *_NS options looks like an easy way to avoid the mess. Dave's patches seem to provide the maximum amount of flexibility, but my suspicion is that most interested parties tend to turn on all of *_NS anyway (as distros are starting to do), and that other configurations (e.g. CHECKPOINT=y, NET_NS=n) simply won't get test coverage in practice.

#7 lore raw

Re: [PATCH 4/4] Conditionally force on namespaces

In reply to a message not in the archive
Quoted 15 lines · Serge E. Hallyn
Quoted 5 lines · Dave Hansen

This should work around the compile issues that Nathan pointed out yesterday. It's too bad that 'select' is such a blunt object. We could surely use a soft select or something. But this hacks around it a bit.

Quoted 8 lines

Create a separate "*_NS_DEP" Kconfig option for the dependencies for each namespace. Make the real config option and the c/r 'select' bot dependent on the new common one.

This should at least keep compile errors from being introduced. Whether this is rude or not is a separate questions. :)

Quoted 6 lines

Yeah I'm not sure I'm a fan of this...

While I hate chasing down missing dependencies, maybe CONFIG_CHECKPOINT should just depend on all the namespaces instead of selecting them?

Current c/r can work without namespaces - it should not depend on CONFIG_NAMESPACE (though it can suggest).

Oren.