[PATCH 1/3] Normalize config options for guest support

[PATCH 1/3] Normalize config options for guest support

[Rusty Russell]

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.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

diff -r 3d3ac181380b arch/i386/Kconfig
--- a/arch/i386/Kconfig	Fri Sep 14 12:24:15 2007 +1000
+++ b/arch/i386/Kconfig	Fri Sep 14 12:45:09 2007 +1000
@@ -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
--- a/arch/i386/xen/Kconfig	Fri Sep 14 12:24:15 2007 +1000
+++ b/arch/i386/xen/Kconfig	Fri Sep 14 12:37:38 2007 +1000
@@ -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
--- a/drivers/lguest/Kconfig	Fri Sep 14 12:24:15 2007 +1000
+++ b/drivers/lguest/Kconfig	Fri Sep 14 12:31:44 2007 +1000
@@ -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

[PATCH 2/3] Consolidate host virtualization support under Virtualization menu

[Rusty Russell]

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.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

diff -r c2893801de2a drivers/Kconfig
--- a/drivers/Kconfig	Fri Sep 14 13:24:46 2007 +1000
+++ b/drivers/Kconfig	Fri Sep 14 13:24:49 2007 +1000
@@ -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
--- a/drivers/kvm/Kconfig	Fri Sep 14 13:24:46 2007 +1000
+++ b/drivers/kvm/Kconfig	Fri Sep 14 13:32:22 2007 +1000
@@ -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

[PATCH 2/3] Consolidate host virtualization support under Virtualization menu

[Rusty Russell]

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.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

diff -r c2893801de2a drivers/Kconfig
--- a/drivers/Kconfig	Fri Sep 14 13:24:46 2007 +1000
+++ b/drivers/Kconfig	Fri Sep 14 13:24:49 2007 +1000
@@ -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
--- a/drivers/kvm/Kconfig	Fri Sep 14 13:24:46 2007 +1000
+++ b/drivers/kvm/Kconfig	Fri Sep 14 13:32:22 2007 +1000
@@ -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

[PATCH 3/3] Time to make CONFIG_PARAVIRT non-experimental.

[Rusty Russell]

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

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> 

diff -r b546335d7e75 arch/i386/Kconfig
--- a/arch/i386/Kconfig	Fri Sep 14 13:24:49 2007 +1000
+++ b/arch/i386/Kconfig	Fri Sep 14 13:27:13 2007 +1000
@@ -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

[PATCH 3/3] Time to make CONFIG_PARAVIRT non-experimental.

[Rusty Russell]

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

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> 

diff -r b546335d7e75 arch/i386/Kconfig
--- a/arch/i386/Kconfig	Fri Sep 14 13:24:49 2007 +1000
+++ b/arch/i386/Kconfig	Fri Sep 14 13:27:13 2007 +1000
@@ -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
 

Re: [PATCH 3/3] Time to make CONFIG_PARAVIRT non-experimental.

[Andi Kleen]

On Friday 14 September 2007 07:21, Rusty Russell wrote:
> It's pretty widely used,

Is it? By whom?

> and the distributions will turn it on. 

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

Re: [PATCH 3/3] Time to make CONFIG_PARAVIRT non-experimental.

[Charles N Wyble]

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



Andi Kleen wrote:
> On Friday 14 September 2007 07:21, Rusty Russell wrote:
>> It's pretty widely used,
> 
> Is it? By whom?
> 
>> and the distributions will turn it on. 
> 
> That's no reason to make it default y. Please undo that. default y
> is near always a bad idea.


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-----

Re: [PATCH 3/3] Time to make CONFIG_PARAVIRT non-experimental.

[Andi Kleen]

> 	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?

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

Re: [PATCH 3/3] Time to make CONFIG_PARAVIRT non-experimental.

[Andi Kleen]

> 	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?

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

Re: [PATCH 3/3] Time to make CONFIG_PARAVIRT non-experimental.

[Charles N Wyble]

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



Andi Kleen wrote:
> 
>> 	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?
> 
> 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.

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.

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

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.

> 
> 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.

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.

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

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

> 
> -Andi
> 
-----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-----

Re: [PATCH 3/3] Time to make CONFIG_PARAVIRT non-experimental.

[Andi Kleen]

 
> 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.

You don't understand it correctly then.

-Andi

Re: [PATCH 3/3] Time to make CONFIG_PARAVIRT non-experimental.

[Andi Kleen]

 
> 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.

You don't understand it correctly then.

-Andi

Re: [PATCH 3/3] Time to make CONFIG_PARAVIRT non-experimental.

[Satyam Sharma]

On Tue, 18 Sep 2007, Charles N Wyble wrote:
> 
> Andi Kleen wrote:
> > 
> > Besides it's bad taste and taste is very important.
> 
> Well it's bad taste for you (one person).

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".

Re: [PATCH 3/3] Time to make CONFIG_PARAVIRT non-experimental.

[Charles N Wyble]

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



Satyam Sharma wrote:
> 
> On Tue, 18 Sep 2007, Charles N Wyble wrote:
>> Andi Kleen wrote:
>>> Besides it's bad taste and taste is very important.
>> Well it's bad taste for you (one person).
> 
> 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".
> 

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-----

Re: [PATCH 3/3] Time to make CONFIG_PARAVIRT non-experimental.

[Charles N Wyble]

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



Satyam Sharma wrote:
> 
> On Tue, 18 Sep 2007, Charles N Wyble wrote:
>> Andi Kleen wrote:
>>> Besides it's bad taste and taste is very important.
>> Well it's bad taste for you (one person).
> 
> 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".
> 

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-----

Re: [PATCH 3/3] Time to make CONFIG_PARAVIRT non-experimental.

[Satyam Sharma]

On Thu, 20 Sep 2007, Charles N Wyble wrote:
> 
> Satyam Sharma wrote:
> > 
> > On Tue, 18 Sep 2007, Charles N Wyble wrote:
> >> Andi Kleen wrote:
> >>> Besides it's bad taste and taste is very important.
> >> Well it's bad taste for you (one person).
> > 
> > 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".
> 
> I am curious why you think it shouldn't be default why? Bad taste? Can
> you provide data about how it will harm things?

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

Re: [PATCH 3/3] Time to make CONFIG_PARAVIRT non-experimental.

[Satyam Sharma]

On Thu, 20 Sep 2007, Charles N Wyble wrote:
> 
> Satyam Sharma wrote:
> > 
> > On Tue, 18 Sep 2007, Charles N Wyble wrote:
> >> Andi Kleen wrote:
> >>> Besides it's bad taste and taste is very important.
> >> Well it's bad taste for you (one person).
> > 
> > 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".
> 
> I am curious why you think it shouldn't be default why? Bad taste? Can
> you provide data about how it will harm things?

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

Re: [PATCH 3/3] Time to make CONFIG_PARAVIRT non-experimental.

[Satyam Sharma]

On Tue, 18 Sep 2007, Charles N Wyble wrote:
> 
> Andi Kleen wrote:
> > 
> > Besides it's bad taste and taste is very important.
> 
> Well it's bad taste for you (one person).

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".

Re: [PATCH 3/3] Time to make CONFIG_PARAVIRT non-experimental.

[Charles N Wyble]

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



Andi Kleen wrote:
> 
>> 	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?
> 
> 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.

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.

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

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.

> 
> 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.

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.

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

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

> 
> -Andi
> 
-----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-----

Re: [PATCH 3/3] Time to make CONFIG_PARAVIRT non-experimental.

[Charles N Wyble]

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



Andi Kleen wrote:
> On Friday 14 September 2007 07:21, Rusty Russell wrote:
>> It's pretty widely used,
> 
> Is it? By whom?
> 
>> and the distributions will turn it on. 
> 
> That's no reason to make it default y. Please undo that. default y
> is near always a bad idea.


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-----

Re: [PATCH 3/3] Time to make CONFIG_PARAVIRT non-experimental.

[Rusty Russell]

On Tue, 2007-09-18 at 12:57 +0200, Andi Kleen wrote:
> On Friday 14 September 2007 07:21, Rusty Russell wrote:
> > It's pretty widely used,
> 
> Is it? By whom?

Hi Andi,

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

> > and the distributions will turn it on. 
> 
> That's no reason to make it default y. Please undo that. default y
> is near always a bad idea.

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

> Also I would still consider it experimental.

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.

Re: [PATCH 3/3] Time to make CONFIG_PARAVIRT non-experimental.

[Andi Kleen]

On Tuesday 18 September 2007 23:34, Rusty Russell wrote:
> On Tue, 2007-09-18 at 12:57 +0200, Andi Kleen wrote:
> > On Friday 14 September 2007 07:21, Rusty Russell wrote:
> > > It's pretty widely used,
> >
> > Is it? By whom?
>
> Hi Andi,
>
> 	Please stop asking for facts!  It's was easy claim to make, and hard to
> disprove 8)
>
> > > and the distributions will turn it on.
> >
> > That's no reason to make it default y. Please undo that. default y
> > is near always a bad idea.
>
> How about a "select" based on Xen, lguest or VMI?  There's no other
> reason to enable it, after all.

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.

> > Also I would still consider it experimental.
>
> After 9 months in mainline and three kernel versions, 

Well it changed a lot each release.

> I'd hope not. 
> It's been pretty damn stable (ok, you broke it once, but maybe that's
> because you consider it experimental).

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

Re: [PATCH 3/3] Time to make CONFIG_PARAVIRT non-experimental.

[Andi Kleen]

On Tuesday 18 September 2007 23:34, Rusty Russell wrote:
> On Tue, 2007-09-18 at 12:57 +0200, Andi Kleen wrote:
> > On Friday 14 September 2007 07:21, Rusty Russell wrote:
> > > It's pretty widely used,
> >
> > Is it? By whom?
>
> Hi Andi,
>
> 	Please stop asking for facts!  It's was easy claim to make, and hard to
> disprove 8)
>
> > > and the distributions will turn it on.
> >
> > That's no reason to make it default y. Please undo that. default y
> > is near always a bad idea.
>
> How about a "select" based on Xen, lguest or VMI?  There's no other
> reason to enable it, after all.

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.

> > Also I would still consider it experimental.
>
> After 9 months in mainline and three kernel versions, 

Well it changed a lot each release.

> I'd hope not. 
> It's been pretty damn stable (ok, you broke it once, but maybe that's
> because you consider it experimental).

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

Re: [PATCH 3/3] Time to make CONFIG_PARAVIRT non-experimental.

[Rusty Russell]

On Tue, 2007-09-18 at 23:52 +0200, Andi Kleen wrote:
> On Tuesday 18 September 2007 23:34, Rusty Russell wrote:
> > How about a "select" based on Xen, lguest or VMI?  There's no other
> > reason to enable it, after all.
> 
> 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.

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.

> > > Also I would still consider it experimental.
> >
> > After 9 months in mainline and three kernel versions, 
> 
> Well it changed a lot each release.

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.

> > I'd hope not. 
> > It's been pretty damn stable (ok, you broke it once, but maybe that's
> > because you consider it experimental).
> 
> Is there a significant user base? 

It's enabled in Ubuntu Feisty (2.6.20).

> 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.

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.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

diff -r 8efa5fdb22d8 arch/i386/Kconfig
--- a/arch/i386/Kconfig	Wed Sep 19 11:23:18 2007 +1000
+++ b/arch/i386/Kconfig	Wed Sep 19 11:33:59 2007 +1000
@@ -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
--- a/arch/i386/xen/Kconfig	Wed Sep 19 11:23:18 2007 +1000
+++ b/arch/i386/xen/Kconfig	Wed Sep 19 11:25:07 2007 +1000
@@ -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

Re: [PATCH 3/3] Time to make CONFIG_PARAVIRT non-experimental.

[Rusty Russell]

On Tue, 2007-09-18 at 23:52 +0200, Andi Kleen wrote:
> On Tuesday 18 September 2007 23:34, Rusty Russell wrote:
> > How about a "select" based on Xen, lguest or VMI?  There's no other
> > reason to enable it, after all.
> 
> 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.

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.

> > > Also I would still consider it experimental.
> >
> > After 9 months in mainline and three kernel versions, 
> 
> Well it changed a lot each release.

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.

> > I'd hope not. 
> > It's been pretty damn stable (ok, you broke it once, but maybe that's
> > because you consider it experimental).
> 
> Is there a significant user base? 

It's enabled in Ubuntu Feisty (2.6.20).

> 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.

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.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

diff -r 8efa5fdb22d8 arch/i386/Kconfig
--- a/arch/i386/Kconfig	Wed Sep 19 11:23:18 2007 +1000
+++ b/arch/i386/Kconfig	Wed Sep 19 11:33:59 2007 +1000
@@ -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
--- a/arch/i386/xen/Kconfig	Wed Sep 19 11:23:18 2007 +1000
+++ b/arch/i386/xen/Kconfig	Wed Sep 19 11:25:07 2007 +1000
@@ -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

Re: [PATCH 3/3] Time to make CONFIG_PARAVIRT non-experimental.

[Jeremy Fitzhardinge]

Andi Kleen wrote:
> 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.
>   

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

Re: [PATCH 3/3] Time to make CONFIG_PARAVIRT non-experimental.

[Jeremy Fitzhardinge]

Andi Kleen wrote:
> 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.
>   

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

Re: [PATCH 3/3] Time to make CONFIG_PARAVIRT non-experimental.

[Ian Campbell]

On Tue, 2007-09-18 at 20:59 -0700, Jeremy Fitzhardinge wrote:
> Andi Kleen wrote:
> > 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.
> >   
> 
> 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.

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

Re: [PATCH 3/3] Time to make CONFIG_PARAVIRT non-experimental.

[Ian Campbell]

On Tue, 2007-09-18 at 20:59 -0700, Jeremy Fitzhardinge wrote:
> Andi Kleen wrote:
> > 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.
> >   
> 
> 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.

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

Re: [PATCH 3/3] Time to make CONFIG_PARAVIRT non-experimental.

[Rusty Russell]

On Tue, 2007-09-18 at 12:57 +0200, Andi Kleen wrote:
> On Friday 14 September 2007 07:21, Rusty Russell wrote:
> > It's pretty widely used,
> 
> Is it? By whom?

Hi Andi,

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

> > and the distributions will turn it on. 
> 
> That's no reason to make it default y. Please undo that. default y
> is near always a bad idea.

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

> Also I would still consider it experimental.

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.

Re: [PATCH 3/3] Time to make CONFIG_PARAVIRT non-experimental.

[Andi Kleen]

On Friday 14 September 2007 07:21, Rusty Russell wrote:
> It's pretty widely used,

Is it? By whom?

> and the distributions will turn it on. 

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

Re: [PATCH 2/3] Consolidate host virtualization support under Virtualization menu

[Randy Dunlap]

On Fri, 14 Sep 2007 15:18:44 +1000 Rusty Russell wrote:

> 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.

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.


> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
> 
> diff -r c2893801de2a drivers/Kconfig
> --- a/drivers/Kconfig	Fri Sep 14 13:24:46 2007 +1000
> +++ b/drivers/Kconfig	Fri Sep 14 13:24:49 2007 +1000
> @@ -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
> --- a/drivers/kvm/Kconfig	Fri Sep 14 13:24:46 2007 +1000
> +++ b/drivers/kvm/Kconfig	Fri Sep 14 13:32:22 2007 +1000
> @@ -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


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: [PATCH 2/3] Consolidate host virtualization support under Virtualization menu

[Jan Engelhardt]

On Sep 14 2007 09:19, Randy Dunlap wrote:
>On Fri, 14 Sep 2007 15:18:44 +1000 Rusty Russell wrote:
>
>> 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.

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
-- 

Re: [PATCH 2/3] Consolidate host virtualization support under Virtualization menu

[Jan Engelhardt]

On Sep 14 2007 09:19, Randy Dunlap wrote:
>On Fri, 14 Sep 2007 15:18:44 +1000 Rusty Russell wrote:
>
>> 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.

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
-- 

Re: [PATCH 2/3] Consolidate host virtualization support under Virtualization menu

[Rusty Russell]

On Fri, 2007-09-14 at 09:19 -0700, Randy Dunlap wrote:
> On Fri, 14 Sep 2007 15:18:44 +1000 Rusty Russell wrote:
> 
> > 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.
> 
> 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.

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.

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

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

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

diff -r c2893801de2a drivers/Kconfig
--- a/drivers/Kconfig	Fri Sep 14 13:24:46 2007 +1000
+++ b/drivers/Kconfig	Fri Sep 14 13:24:49 2007 +1000
@@ -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
--- a/drivers/kvm/Kconfig	Fri Sep 14 13:24:46 2007 +1000
+++ b/drivers/kvm/Kconfig	Fri Sep 14 13:32:22 2007 +1000
@@ -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

Re: [PATCH 2/3] Consolidate host virtualization support under Virtualization menu

[Alexey Eremenko]

> 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.

What about containerization bits ?

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

-- 
-Alexey Eremenko "Technologov"

Re: [PATCH 2/3] Consolidate host virtualization support under Virtualization menu

[Rusty Russell]

On Sat, 2007-09-15 at 11:49 +0300, Alexey Eremenko wrote:
> > 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.
> 
> What about containerization bits ?
> 
> IPC_Namespaces, *_Namespaces  - I think we should evaluate adding them
> too to this menu.

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

Rusty.

Re: [PATCH 2/3] Consolidate host virtualization support under Virtualization menu

[Rusty Russell]

On Sat, 2007-09-15 at 11:49 +0300, Alexey Eremenko wrote:
> > 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.
> 
> What about containerization bits ?
> 
> IPC_Namespaces, *_Namespaces  - I think we should evaluate adding them
> too to this menu.

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

Rusty.

Re: [PATCH 2/3] Consolidate host virtualization support under Virtualization menu

[Jeremy Fitzhardinge]

Rusty Russell wrote:
> Well, containerization deserves its own menu, but the question is does i
> it belong under this menu?

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

Re: [PATCH 2/3] Consolidate host virtualization support under Virtualization menu

[Zachary Amsden]

On Sun, 2007-09-16 at 07:56 -0700, Jeremy Fitzhardinge wrote:
> Rusty Russell wrote:
> > Well, containerization deserves its own menu, but the question is does i
> > it belong under this menu?
> 
> 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.

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

Re: [PATCH 2/3] Consolidate host virtualization support under Virtualization menu

[Charles N Wyble]

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



Zachary Amsden wrote:
<snip>>
> Virtualization is completely different, and probably needs separate
> server (kvm, lguest) and client (kvm, lguest, xen, vmware) sections in
> it's menu.


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

>
> Zach
>
> _______________________________________________
> Virtualization mailing list
> Virtualization@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/virtualization
>
-----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-----

Re: [PATCH 2/3] Consolidate host virtualization support under Virtualization menu

[Charles N Wyble]

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



Zachary Amsden wrote:
<snip>>
> Virtualization is completely different, and probably needs separate
> server (kvm, lguest) and client (kvm, lguest, xen, vmware) sections in
> it's menu.


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

>
> Zach
>
> _______________________________________________
> Virtualization mailing list
> Virtualization@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/virtualization
>
-----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-----

Re: [PATCH 2/3] Consolidate host virtualization support under Virtualization menu

[Jeremy Fitzhardinge]

Charles N Wyble wrote:
>
>
> Zachary Amsden wrote:
> <snip>>
> > Virtualization is completely different, and probably needs separate
> > server (kvm, lguest) and client (kvm, lguest, xen, vmware) sections in
> > it's menu.
>
>
> So what is the differentiation between client and server above? Just
> curious what makes kvm and lguest server and client.

"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

Re: [PATCH 2/3] Consolidate host virtualization support under Virtualization menu

[Charles N Wyble]

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



Jeremy Fitzhardinge wrote:
> Charles N Wyble wrote:
>>
>> Zachary Amsden wrote:
>> <snip>>
>>> Virtualization is completely different, and probably needs separate
>>> server (kvm, lguest) and client (kvm, lguest, xen, vmware) sections in
>>> it's menu.
>>
>> So what is the differentiation between client and server above? Just
>> curious what makes kvm and lguest server and client.
> 
> "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


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-----

Re: [PATCH 2/3] Consolidate host virtualization support under Virtualization menu

[Charles N Wyble]

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



Jeremy Fitzhardinge wrote:
> Charles N Wyble wrote:
>>
>> Zachary Amsden wrote:
>> <snip>>
>>> Virtualization is completely different, and probably needs separate
>>> server (kvm, lguest) and client (kvm, lguest, xen, vmware) sections in
>>> it's menu.
>>
>> So what is the differentiation between client and server above? Just
>> curious what makes kvm and lguest server and client.
> 
> "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


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-----

Re: [PATCH 2/3] Consolidate host virtualization support under Virtualization menu

[Alexey Eremenko]

On 9/18/07, Charles N Wyble <charles@thewybles.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > "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.
> >

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"

Re: [PATCH 2/3] Consolidate host virtualization support under Virtualization menu

[Alexey Eremenko]

On 9/18/07, Charles N Wyble <charles@thewybles.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > "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.
> >

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"

Re: [PATCH 2/3] Consolidate host virtualization support under Virtualization menu

[Jeremy Fitzhardinge]

Charles N Wyble wrote:
>
>
> Zachary Amsden wrote:
> <snip>>
> > Virtualization is completely different, and probably needs separate
> > server (kvm, lguest) and client (kvm, lguest, xen, vmware) sections in
> > it's menu.
>
>
> So what is the differentiation between client and server above? Just
> curious what makes kvm and lguest server and client.

"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

Re: [PATCH 2/3] Consolidate host virtualization support under Virtualization menu

[Zachary Amsden]

On Sun, 2007-09-16 at 07:56 -0700, Jeremy Fitzhardinge wrote:
> Rusty Russell wrote:
> > Well, containerization deserves its own menu, but the question is does i
> > it belong under this menu?
> 
> 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.

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

Re: [PATCH 2/3] Consolidate host virtualization support under Virtualization menu

[Jeremy Fitzhardinge]

Rusty Russell wrote:
> Well, containerization deserves its own menu, but the question is does i
> it belong under this menu?

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

Re: [PATCH 2/3] Consolidate host virtualization support under Virtualization menu

[Alexey Eremenko]

> 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.

What about containerization bits ?

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

-- 
-Alexey Eremenko "Technologov"

Re: [PATCH 2/3] Consolidate host virtualization support under Virtualization menu

[Rusty Russell]

On Fri, 2007-09-14 at 09:19 -0700, Randy Dunlap wrote:
> On Fri, 14 Sep 2007 15:18:44 +1000 Rusty Russell wrote:
> 
> > 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.
> 
> 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.

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.

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

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

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

diff -r c2893801de2a drivers/Kconfig
--- a/drivers/Kconfig	Fri Sep 14 13:24:46 2007 +1000
+++ b/drivers/Kconfig	Fri Sep 14 13:24:49 2007 +1000
@@ -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
--- a/drivers/kvm/Kconfig	Fri Sep 14 13:24:46 2007 +1000
+++ b/drivers/kvm/Kconfig	Fri Sep 14 13:32:22 2007 +1000
@@ -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

Re: [PATCH 2/3] Consolidate host virtualization support under Virtualization menu

[Randy Dunlap]

On Fri, 14 Sep 2007 15:18:44 +1000 Rusty Russell wrote:

> 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.

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.


> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
> 
> diff -r c2893801de2a drivers/Kconfig
> --- a/drivers/Kconfig	Fri Sep 14 13:24:46 2007 +1000
> +++ b/drivers/Kconfig	Fri Sep 14 13:24:49 2007 +1000
> @@ -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
> --- a/drivers/kvm/Kconfig	Fri Sep 14 13:24:46 2007 +1000
> +++ b/drivers/kvm/Kconfig	Fri Sep 14 13:32:22 2007 +1000
> @@ -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


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***