Normalize config options for guest support

Group all the "guest OS" support options together, under CONFIG_PARAVIRT. Make this a proper menu item so it looks neater on menuconfig etc, and make the wording for each prompt uniform.

diff -r 3d3ac181380b arch/i386/Kconfig
@@ -214,28 +214,38 @@ config X86_ES7000
 
 endchoice
 
-config PARAVIRT
-	bool "Paravirtualization support (EXPERIMENTAL)"
+menuconfig PARAVIRT
+	bool "Paravirtualized guest support (EXPERIMENTAL)"
 	depends on EXPERIMENTAL
 	depends on !(X86_VISWS || X86_VOYAGER)
 	help
 	  Paravirtualization is a way of running multiple instances of
 	  Linux on the same machine, under a hypervisor.  This option
 	  changes the kernel so it can modify itself when it is run
 	  under a hypervisor, improving performance significantly.
 	  However, when run without a hypervisor the kernel is
 	  theoretically slower.  If in doubt, say N.
+
+if PARAVIRT
 
 source "arch/i386/xen/Kconfig"
 
 config VMI
-	bool "VMI Paravirt-ops support"
-	depends on PARAVIRT
+	bool "VMI Guest support"
 	help
 	  VMI provides a paravirtualized interface to the VMware ESX server
 	  (it could be used by other hypervisors in theory too, but is not
 	  at the moment), by linking the kernel to a GPL-ed ROM module
 	  provided by the hypervisor.
+
+config LGUEST_GUEST
+	bool "Lguest guest support"
+	depends on !X86_PAE
+	help
+	  Lguest is a tiny in-kernel hypervisor.  Selecting this will
+	  allow your kernel to boot under lguest.  This option will increase
+	  your kernel size by about 6k.  If in doubt, say N.
+endif
 
 config ACPI_SRAT
 	bool

diff -r 3d3ac181380b arch/i386/xen/Kconfig
@@ -3,8 +3,8 @@
 #
 
 config XEN
-	bool "Enable support for Xen hypervisor"
-	depends on PARAVIRT && X86_CMPXCHG && X86_TSC && !NEED_MULTIPLE_NODES
+	bool "Xen guest support"
+	depends on X86_CMPXCHG && X86_TSC && !NEED_MULTIPLE_NODES
 	help
 	  This is the Linux Xen port.  Enabling this will allow the
 	  kernel to boot in a paravirtualized environment under the

diff -r 3d3ac181380b drivers/lguest/Kconfig
@@ -1,23 +1,18 @@ config LGUEST
 config LGUEST
 	tristate "Linux hypervisor example code"
-	depends on X86 && PARAVIRT && EXPERIMENTAL && !X86_PAE && FUTEX
-	select LGUEST_GUEST
+	depends on X86 && EXPERIMENTAL && !X86_PAE && FUTEX
 	select HVC_DRIVER
 	---help---
-	  This is a very simple module which allows you to run
-	  multiple instances of the same Linux kernel, using the
+	  This is a very simple module called lg.ko which allows you to run
+	  multiple instances of the Linux kernel, using the
 	  "lguest" command found in the Documentation/lguest directory.
 	  Note that "lguest" is pronounced to rhyme with "fell quest",
 	  not "rustyvisor".  See Documentation/lguest/lguest.txt.
 
+	  Usually you would also turn on "Lguest guest support", to create a
+	  kernel which can also boot under lguest.
+
 	  If unsure, say N.  If curious, say M.  If masochistic, say Y.
-
-config LGUEST_GUEST
-	bool
-	help
-	  The guest needs code built-in, even if the host has lguest
-	  support as a module.  The drivers are tiny, so we build them
-	  in too.
 
 config LGUEST_NET
 	tristate

We turn "Virtualization" into a menu, not a config option, since it's actually only used as a menu. Then we move lguest under that menu.

diff -r c2893801de2a drivers/Kconfig
@@ -87,6 +87,4 @@ source "drivers/kvm/Kconfig"
 source "drivers/kvm/Kconfig"
 
 source "drivers/uio/Kconfig"
-
-source "drivers/lguest/Kconfig"
 endmenu

diff -r c2893801de2a drivers/kvm/Kconfig
@@ -1,21 +1,12 @@
 #
 # KVM configuration
 #
-menuconfig VIRTUALIZATION
-	bool "Virtualization"
+menu "Virtualization"
 	depends on X86
-	default y
-	---help---
-	  Say Y here to get to see options for virtualization guest drivers.
-	  This option alone does not add any kernel code.
-
-	  If you say N, all options in this submenu will be skipped and disabled.
-
-if VIRTUALIZATION
 
 config KVM
 	tristate "Kernel-based Virtual Machine (KVM) support"
-	depends on X86 && EXPERIMENTAL
+	depends on EXPERIMENTAL
 	select ANON_INODES
 	---help---
 	  Support hosting fully virtualized guest machines using hardware

@@ -45,4 +36,8 @@ config KVM_AMD
 	  Provides support for KVM on AMD processors equipped with the AMD-V
 	  (SVM) extensions.
 
-endif # VIRTUALIZATION
+# OK, it's a little counter-intuitive to do this, but it puts it neatly under
+# the virtualization menu.
+source drivers/lguest/Kconfig
+
+endmenu

We turn "Virtualization" into a menu, not a config option, since it's actually only used as a menu. Then we move lguest under that menu.

diff -r c2893801de2a drivers/Kconfig
@@ -87,6 +87,4 @@ source "drivers/kvm/Kconfig"
 source "drivers/kvm/Kconfig"
 
 source "drivers/uio/Kconfig"
-
-source "drivers/lguest/Kconfig"
 endmenu

diff -r c2893801de2a drivers/kvm/Kconfig
@@ -1,21 +1,12 @@
 #
 # KVM configuration
 #
-menuconfig VIRTUALIZATION
-	bool "Virtualization"
+menu "Virtualization"
 	depends on X86
-	default y
-	---help---
-	  Say Y here to get to see options for virtualization guest drivers.
-	  This option alone does not add any kernel code.
-
-	  If you say N, all options in this submenu will be skipped and disabled.
-
-if VIRTUALIZATION
 
 config KVM
 	tristate "Kernel-based Virtual Machine (KVM) support"
-	depends on X86 && EXPERIMENTAL
+	depends on EXPERIMENTAL
 	select ANON_INODES
 	---help---
 	  Support hosting fully virtualized guest machines using hardware

@@ -45,4 +36,8 @@ config KVM_AMD
 	  Provides support for KVM on AMD processors equipped with the AMD-V
 	  (SVM) extensions.
 
-endif # VIRTUALIZATION
+# OK, it's a little counter-intuitive to do this, but it puts it neatly under
+# the virtualization menu.
+source drivers/lguest/Kconfig
+
+endmenu

It's pretty widely used, and the distributions will turn it on.

diff -r b546335d7e75 arch/i386/Kconfig
@@ -215,8 +215,8 @@ endchoice
 endchoice
 
 menuconfig PARAVIRT
-	bool "Paravirtualized guest support (EXPERIMENTAL)"
-	depends on EXPERIMENTAL
+	bool "Paravirtualized guest support"
+	default y
 	depends on !(X86_VISWS || X86_VOYAGER)
 	help
 	  Paravirtualization is a way of running multiple instances of

@@ -224,7 +224,7 @@ menuconfig PARAVIRT
 	  changes the kernel so it can modify itself when it is run
 	  under a hypervisor, improving performance significantly.
 	  However, when run without a hypervisor the kernel is
-	  theoretically slower.  If in doubt, say N.
+	  theoretically slower.  If in doubt, say Y.
 
 if PARAVIRT

It's pretty widely used, and the distributions will turn it on.

diff -r b546335d7e75 arch/i386/Kconfig
@@ -215,8 +215,8 @@ endchoice
 endchoice
 
 menuconfig PARAVIRT
-	bool "Paravirtualized guest support (EXPERIMENTAL)"
-	depends on EXPERIMENTAL
+	bool "Paravirtualized guest support"
+	default y
 	depends on !(X86_VISWS || X86_VOYAGER)
 	help
 	  Paravirtualization is a way of running multiple instances of

@@ -224,7 +224,7 @@ menuconfig PARAVIRT
 	  changes the kernel so it can modify itself when it is run
 	  under a hypervisor, improving performance significantly.
 	  However, when run without a hypervisor the kernel is
-	  theoretically slower.  If in doubt, say N.
+	  theoretically slower.  If in doubt, say Y.
 
 if PARAVIRT
 

Is it? By whom?

That's no reason to make it default y. Please undo that. default y is near always a bad idea.

Also I would still consider it experimental.

-Andi

Is it? By whom?

That's no reason to make it default y. Please undo that. default y is near always a bad idea.

Also I would still consider it experimental.

-Andi

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andi,

What do you base this on? Why is making something default y a bad idea?
Those most likely to care can turn it off. Is there a harmful effect from leaving it on if its not being used?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG8C9QkQPZV56XDBMRAowcAJ9fkxKAjjsvGd6hOPkvHXU9ThpoQwCdGUI8 mjpUh6G+ZyzL0CW3sYNS97g=
=ZgiJ
-----END PGP SIGNATURE-----

Running yes "" | make oldconfig to upgrade kernel configs is standard practice and you definitely don't want to have all kinds of random new unnecessary features be turned on then.

Besides paravirt by itself is pretty useless; you need typically quite complex other options set to do any meaningfull virtualization.

The only reason to use default y is in options that are not user visible and have a reasonable default or things that cause direct boot failures when upgrading old configurations. That all doesn't apply here.

Besides it's bad taste and taste is very important.

-Andi

Running yes "" | make oldconfig to upgrade kernel configs is standard practice and you definitely don't want to have all kinds of random new unnecessary features be turned on then.

Besides paravirt by itself is pretty useless; you need typically quite complex other options set to do any meaningfull virtualization.

The only reason to use default y is in options that are not user visible and have a reasonable default or things that cause direct boot failures when upgrading old configurations. That all doesn't apply here.

Besides it's bad taste and taste is very important.

-Andi

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hmmmm. I disagree its a standard practice. I thought the whole point of make oldconfig was to give you just the delta in configuration options and was targeted at manual review?

Also how many people are building there own kernels these days? Expanding on what I said in the original e-mail those who are likely to care "CAN TURN IT OFF". Those who care about such things should be REVIEWING CHANGES anyway. Thats what I do when looking at building custom kernels. What changed that makes me want to move to a new version?

I generally try to stick with the distro kernel when possible, but part of being an early and aggressive adopter of virtualization technology involves running non distro kernels and patches.

Most people don't really care.

Actually if I understand the functionality of paravirt correctly that is not correct. I believe that will turn on the paravirt bits which allow it to run under things such as VMI or Xen.

Again you need to think about the target audience here. A distro kernel you don't have to worry about this stuff. A user compiling there own kernel should already be able to handle this.

Well it's bad taste for you (one person). Taste is highly subjective. So be careful in making broad ranging statements like this. :)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG8DSnkQPZV56XDBMRAtZcAJ4rtRXGW14b70YRIBKyHCsaKTdO/wCeOdoM AUc4YGUaqs5DmDDbov7X980=
=UA4y
-----END PGP SIGNATURE-----

You don't understand it correctly then.

-Andi

You don't understand it correctly then.

-Andi

FWIW, my opinion is the same as Andi's here. Please, let's avoid this disease -- unless *absolutely* required, stuff shouldn't be "default y".

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I am curious why you think it shouldn't be default why? Bad taste? Can you provide data about how it will harm things?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG8ptLkQPZV56XDBMRApxNAJwLOv2dabO6KD6t4Z/Fkffelh1IxwCdEzPM 1JEuIQvlkiojgiMy0tnroqk=
=yCiZ
-----END PGP SIGNATURE-----

Clear CONFIG_PARAVIRT from your .config and try "make oldconfig", and find out for yourself :-)

You'll end up having to answer questions for all other config options below it, that you never cared about, that you didn't know even existed. You'd obviously (I would, at least) feel annoyed by it all ... this is almost a regression :-)

And for those who automate the oldconfig process using "yes", well, this "default y" *will* end up introducing a kernel text size regression -- all those config options they never had earlier, suddenly got enabled.

Besides, like Andi said, selecting or enabling CONFIG_PARAVIRT is quite pointless in the first place -- it's just a menuconfig symbol, not a "real" kconfig symbol that _actually_ controls code in the Makefiles.

Satyam

Clear CONFIG_PARAVIRT from your .config and try "make oldconfig", and find out for yourself :-)

You'll end up having to answer questions for all other config options below it, that you never cared about, that you didn't know even existed. You'd obviously (I would, at least) feel annoyed by it all ... this is almost a regression :-)

And for those who automate the oldconfig process using "yes", well, this "default y" *will* end up introducing a kernel text size regression -- all those config options they never had earlier, suddenly got enabled.

Besides, like Andi said, selecting or enabling CONFIG_PARAVIRT is quite pointless in the first place -- it's just a menuconfig symbol, not a "real" kconfig symbol that _actually_ controls code in the Makefiles.

Satyam

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I am curious why you think it shouldn't be default why? Bad taste? Can you provide data about how it will harm things?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG8ptLkQPZV56XDBMRApxNAJwLOv2dabO6KD6t4Z/Fkffelh1IxwCdEzPM 1JEuIQvlkiojgiMy0tnroqk=
=yCiZ
-----END PGP SIGNATURE-----

FWIW, my opinion is the same as Andi's here. Please, let's avoid this disease -- unless *absolutely* required, stuff shouldn't be "default y".

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hmmmm. I disagree its a standard practice. I thought the whole point of make oldconfig was to give you just the delta in configuration options and was targeted at manual review?

Also how many people are building there own kernels these days? Expanding on what I said in the original e-mail those who are likely to care "CAN TURN IT OFF". Those who care about such things should be REVIEWING CHANGES anyway. Thats what I do when looking at building custom kernels. What changed that makes me want to move to a new version?

I generally try to stick with the distro kernel when possible, but part of being an early and aggressive adopter of virtualization technology involves running non distro kernels and patches.

Most people don't really care.

Actually if I understand the functionality of paravirt correctly that is not correct. I believe that will turn on the paravirt bits which allow it to run under things such as VMI or Xen.

Again you need to think about the target audience here. A distro kernel you don't have to worry about this stuff. A user compiling there own kernel should already be able to handle this.

Well it's bad taste for you (one person). Taste is highly subjective. So be careful in making broad ranging statements like this. :)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG8DSnkQPZV56XDBMRAtZcAJ4rtRXGW14b70YRIBKyHCsaKTdO/wCeOdoM AUc4YGUaqs5DmDDbov7X980=
=UA4y
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andi,

What do you base this on? Why is making something default y a bad idea?
Those most likely to care can turn it off. Is there a harmful effect from leaving it on if its not being used?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG8C9QkQPZV56XDBMRAowcAJ9fkxKAjjsvGd6hOPkvHXU9ThpoQwCdGUI8 mjpUh6G+ZyzL0CW3sYNS97g=
=ZgiJ
-----END PGP SIGNATURE-----

Hi Andi,

Please stop asking for facts! It's was easy claim to make, and hard to
disprove 8)

How about a "select" based on Xen, lguest or VMI? There's no other reason to enable it, after all.

After 9 months in mainline and three kernel versions, I'd hope not. It's been pretty damn stable (ok, you broke it once, but maybe that's because you consider it experimental).

Cheers,
Rusty.

Hi Andi,

Please stop asking for facts! It's was easy claim to make, and hard to
disprove 8)

How about a "select" based on Xen, lguest or VMI? There's no other reason to enable it, after all.

After 9 months in mainline and three kernel versions, I'd hope not. It's been pretty damn stable (ok, you broke it once, but maybe that's because you consider it experimental).

Cheers,
Rusty.

I did an patch to do that recently because the current setup is indeed unobvious.

But I had to drop it again because
it ended up with Kconfig warnings. about undefined symbols on x86-64. The problem is that lguest
is visible in Kconfig for all architectures and it warns if you select something that doesn't exist on all architectures.

The only workaround would have been to define PARAVIRT for all architectures, which I considered too ugly.

I think Sam stated recently he wanted to remove that warning but it needed some infrastructure work.

Well it changed a lot each release.

Is there a significant user base?

At least the Xen port seems to have specific requirements and essentially only work on xen-unstable (?) [or at least some very new Xen version] which probably very few people use.

-Andi

I did an patch to do that recently because the current setup is indeed unobvious.

But I had to drop it again because
it ended up with Kconfig warnings. about undefined symbols on x86-64. The problem is that lguest
is visible in Kconfig for all architectures and it warns if you select something that doesn't exist on all architectures.

The only workaround would have been to define PARAVIRT for all architectures, which I considered too ugly.

I think Sam stated recently he wanted to remove that warning but it needed some infrastructure work.

Well it changed a lot each release.

Is there a significant user base?

At least the Xen port seems to have specific requirements and essentially only work on xen-unstable (?) [or at least some very new Xen version] which probably very few people use.

-Andi

I think that's fixed as a side-effect of this cleanup. At least, it works for me on x86-64. Patch below: if you agree, I'll re-xmit all three.

Well, the biggest change was the patching code getting enhanced in 2.6.22 (to cover all calls, not just 5). The 22 -> 23 changes were fairly trivial.

So I think 2.6.24 is a reasonable time to remove EXPERIMENTAL.

It's enabled in Ubuntu Feisty (2.6.20).

Sure, and that might well still be experimental (Jeremy?). But that's not CONFIG_PARAVIRT.

Hope that helps,
Rusty.
==
Andi points out that PARAVIRT is an option best selected when needed.

We introduce PARAVIRT_GUEST for the menu itself, and select PARAVIRT if they ask for anything which needs it. This also makes PARAVIRT non-experimental.

diff -r 8efa5fdb22d8 arch/i386/Kconfig
@@ -214,24 +214,30 @@ config X86_ES7000
 
 endchoice
 
-menuconfig PARAVIRT
+config PARAVIRT
+	bool
+	depends on !(X86_VISWS || X86_VOYAGER)
+	help
+	  This changes the kernel so it can modify itself when it is run
+	  under a hypervisor, potentially improving performance significantly
+	  over full virtualization.  However, when run without a hypervisor
+	  the kernel is theoretically slower and slightly larger.
+
+menuconfig PARAVIRT_GUEST
-	bool "Paravirtualized guest support (EXPERIMENTAL)"
-	depends on EXPERIMENTAL
+	bool "Paravirtualized guest support"
-	depends on !(X86_VISWS || X86_VOYAGER)
-	help
-	  Paravirtualization is a way of running multiple instances of
-	  Linux on the same machine, under a hypervisor.  This option
-	  changes the kernel so it can modify itself when it is run
-	  under a hypervisor, improving performance significantly.
-	  However, when run without a hypervisor the kernel is
-	  theoretically slower.  If in doubt, say N.
-
-if PARAVIRT
+	help
+	  Say Y here to get to see options related to running Linux under
+	  various hypervisors.  This option alone does not add any kernel code.
+
+	  If you say N, all options in this submenu will be skipped and disabled.
+
+if PARAVIRT_GUEST
 
 source "arch/i386/xen/Kconfig"
 
 config VMI
 	bool "VMI Guest support"
+	select PARAVIRT
 	help
 	  VMI provides a paravirtualized interface to the VMware ESX server
 	  (it could be used by other hypervisors in theory too, but is not

@@ -239,6 +246,7 @@ config VMI
 
 config LGUEST_GUEST
 	bool "Lguest guest support"
+	select PARAVIRT
 	depends on !X86_PAE
 	help
 	  Lguest is a tiny in-kernel hypervisor.  Selecting this will

diff -r 8efa5fdb22d8 arch/i386/xen/Kconfig
@@ -4,6 +4,7 @@
 
 config XEN
 	bool "Xen guest support"
+	select PARAVIRT
 	depends on X86_CMPXCHG && X86_TSC && !NEED_MULTIPLE_NODES
 	help
 	  This is the Linux Xen port.  Enabling this will allow the

I think that's fixed as a side-effect of this cleanup. At least, it works for me on x86-64. Patch below: if you agree, I'll re-xmit all three.

Well, the biggest change was the patching code getting enhanced in 2.6.22 (to cover all calls, not just 5). The 22 -> 23 changes were fairly trivial.

So I think 2.6.24 is a reasonable time to remove EXPERIMENTAL.

It's enabled in Ubuntu Feisty (2.6.20).

Sure, and that might well still be experimental (Jeremy?). But that's not CONFIG_PARAVIRT.

Hope that helps,
Rusty.
==
Andi points out that PARAVIRT is an option best selected when needed.

We introduce PARAVIRT_GUEST for the menu itself, and select PARAVIRT if they ask for anything which needs it. This also makes PARAVIRT non-experimental.

diff -r 8efa5fdb22d8 arch/i386/Kconfig
@@ -214,24 +214,30 @@ config X86_ES7000
 
 endchoice
 
-menuconfig PARAVIRT
+config PARAVIRT
+	bool
+	depends on !(X86_VISWS || X86_VOYAGER)
+	help
+	  This changes the kernel so it can modify itself when it is run
+	  under a hypervisor, potentially improving performance significantly
+	  over full virtualization.  However, when run without a hypervisor
+	  the kernel is theoretically slower and slightly larger.
+
+menuconfig PARAVIRT_GUEST
-	bool "Paravirtualized guest support (EXPERIMENTAL)"
-	depends on EXPERIMENTAL
+	bool "Paravirtualized guest support"
-	depends on !(X86_VISWS || X86_VOYAGER)
-	help
-	  Paravirtualization is a way of running multiple instances of
-	  Linux on the same machine, under a hypervisor.  This option
-	  changes the kernel so it can modify itself when it is run
-	  under a hypervisor, improving performance significantly.
-	  However, when run without a hypervisor the kernel is
-	  theoretically slower.  If in doubt, say N.
-
-if PARAVIRT
+	help
+	  Say Y here to get to see options related to running Linux under
+	  various hypervisors.  This option alone does not add any kernel code.
+
+	  If you say N, all options in this submenu will be skipped and disabled.
+
+if PARAVIRT_GUEST
 
 source "arch/i386/xen/Kconfig"
 
 config VMI
 	bool "VMI Guest support"
+	select PARAVIRT
 	help
 	  VMI provides a paravirtualized interface to the VMware ESX server
 	  (it could be used by other hypervisors in theory too, but is not

@@ -239,6 +246,7 @@ config VMI
 
 config LGUEST_GUEST
 	bool "Lguest guest support"
+	select PARAVIRT
 	depends on !X86_PAE
 	help
 	  Lguest is a tiny in-kernel hypervisor.  Selecting this will

diff -r 8efa5fdb22d8 arch/i386/xen/Kconfig
@@ -4,6 +4,7 @@
 
 config XEN
 	bool "Xen guest support"
+	select PARAVIRT
 	depends on X86_CMPXCHG && X86_TSC && !NEED_MULTIPLE_NODES
 	help
 	  This is the Linux Xen port.  Enabling this will allow the

Only on 64-bit hosts, because of bugs in the 64-bit compat layer. 32-on-32 and 64-on-64 (when its done) should work fine.

BTW, what does "xm info" say on your system that fails? I'll try to put a more graceful failure in there.

J

Only on 64-bit hosts, because of bugs in the 64-bit compat layer. 32-on-32 and 64-on-64 (when its done) should work fine.

BTW, what does "xm info" say on your system that fails? I'll try to put a more graceful failure in there.

J

All the required fixes for 32on64 are queued for Xen 3.1.1 too. The proposed updates are at
http://xenbits.xensource.com/xen-3.1-testing.pq.hg

Ian.

Ian Campbell
Current Noise: Detonation - Sword-Carved Skin

The executioner is, I hear, very expert, and my neck is very slender.
		-- Anne Boleyn

so you want to revert the 2007-july-16 merge that changes menu -> menuconfig and makes most of the menus consistent in presentation. I'd rather not, but I don't own it.

And Yes, lguest does need to be moved into a better location.

so you want to revert the 2007-july-16 merge that changes menu -> menuconfig and makes most of the menus consistent in presentation. I'd rather not, but I don't own it.

And Yes, lguest does need to be moved into a better location.

Whatever, keep it as menuconfig. I want to disable it _at once_ without having to enter the menu, which is the primary motivation having it as 'menuconfig'.

Jan

Whatever, keep it as menuconfig. I want to disable it _at once_ without having to enter the menu, which is the primary motivation having it as 'menuconfig'.

Jan

Ok, I missed that one. To me it seems gratuitous to create a config option simply to control a menu. However if that is considered the Right Way, here is the "Just move lguest" variant.

Indeed,
Rusty.
===
Move lguest under the virtualization menu.

diff -r c2893801de2a drivers/Kconfig
@@ -87,6 +87,4 @@ source "drivers/kvm/Kconfig"
 source "drivers/kvm/Kconfig"
 
 source "drivers/uio/Kconfig"
-
-source "drivers/lguest/Kconfig"
 endmenu

diff -r c2893801de2a drivers/kvm/Kconfig
@@ -45,4 +36,8 @@ config KVM_AMD
 	  Provides support for KVM on AMD processors equipped with the AMD-V
 	  (SVM) extensions.
 
-endif # VIRTUALIZATION
+# OK, it's a little counter-intuitive to do this, but it puts it neatly under
+# the virtualization menu.
+source drivers/lguest/Kconfig
+
+endif # VIRTUALIZATION

Ok, I missed that one. To me it seems gratuitous to create a config option simply to control a menu. However if that is considered the Right Way, here is the "Just move lguest" variant.

Indeed,
Rusty.
===
Move lguest under the virtualization menu.

diff -r c2893801de2a drivers/Kconfig
@@ -87,6 +87,4 @@ source "drivers/kvm/Kconfig"
 source "drivers/kvm/Kconfig"
 
 source "drivers/uio/Kconfig"
-
-source "drivers/lguest/Kconfig"
 endmenu

diff -r c2893801de2a drivers/kvm/Kconfig
@@ -45,4 +36,8 @@ config KVM_AMD
 	  Provides support for KVM on AMD processors equipped with the AMD-V
 	  (SVM) extensions.
 
-endif # VIRTUALIZATION
+# OK, it's a little counter-intuitive to do this, but it puts it neatly under
+# the virtualization menu.
+source drivers/lguest/Kconfig
+
+endif # VIRTUALIZATION

What about containerization bits ?

IPC_Namespaces, *_Namespaces - I think we should evaluate adding them too to this menu.

-Alexey Eremenko "Technologov"

What about containerization bits ?

IPC_Namespaces, *_Namespaces - I think we should evaluate adding them too to this menu.

-Alexey Eremenko "Technologov"

Well, containerization deserves its own menu, but the question is does i it belong under this menu?

Rusty.

Well, containerization deserves its own menu, but the question is does i it belong under this menu?

Rusty.

No, I don't think so. While there are some broad similarities in effect, the technology is completely different, as are the capabilities and tradeoffs. They're pretty much orthogonal.

J

No, I don't think so. While there are some broad similarities in effect, the technology is completely different, as are the capabilities and tradeoffs. They're pretty much orthogonal.

J

It seems to me containerization is much more similar a feature to SYSV IPC, process accounting / auditing, and should be an option under General setup, possibly with its own submenu. Nearly all the features under general setup provide optional extensions to kernel services available from userspace, and so it seems containerization falls naturally into that category.

Virtualization is completely different, and probably needs separate server (kvm, lguest) and client (kvm, lguest, xen, vmware) sections in it's menu.

Zach

It seems to me containerization is much more similar a feature to SYSV IPC, process accounting / auditing, and should be an option under General setup, possibly with its own submenu. Nearly all the features under general setup provide optional extensions to kernel services available from userspace, and so it seems containerization falls naturally into that category.

Virtualization is completely different, and probably needs separate server (kvm, lguest) and client (kvm, lguest, xen, vmware) sections in it's menu.

Zach

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Zachary Amsden wrote:
<snip>>

So what is the differentiation between client and server above? Just curious what makes kvm and lguest server and client.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG7w3ckQPZV56XDBMRAvvaAJ9cHl+A321MJyw6W4J4yIDurz0K2wCcDg8J uOR6alAGvWjxEbThiuaeIDc=
=TQ3m
-----END PGP SIGNATURE-----

"Host" and "guest" are better terms, I think. Kvm is all host, since guests need no modification. lguest turns the kernel into both host and guest. Xen Linux kernels are all guest, since the Xen hypervisor is the host.

J

"Host" and "guest" are better terms, I think. Kvm is all host, since guests need no modification. lguest turns the kernel into both host and guest. Xen Linux kernels are all guest, since the Xen hypervisor is the host.

J

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ah ok. Thank you so much for the clarification. :)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD4DBQFG8DDdkQPZV56XDBMRAl6NAJ90z7tRO+xAvbOOkKeKH6LZWGjNSACYms3u dqGGgl1GOFraS08UmEf++A==
=HgFC
-----END PGP SIGNATURE-----

Yes, I also prefer terms like "Host" and "Guest". Those terms are more correct than "Server" and "Client", which are often reffered to TCP/UDP port listening and network connection.

-Alexey Eremenko "Technologov"

Yes, I also prefer terms like "Host" and "Guest". Those terms are more correct than "Server" and "Client", which are often reffered to TCP/UDP port listening and network connection.

-Alexey Eremenko "Technologov"

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ah ok. Thank you so much for the clarification. :)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD4DBQFG8DDdkQPZV56XDBMRAl6NAJ90z7tRO+xAvbOOkKeKH6LZWGjNSACYms3u dqGGgl1GOFraS08UmEf++A==
=HgFC
-----END PGP SIGNATURE-----