All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zachary Amsden <zach@vmware.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Jeff Dike <jdike@addtoit.com>,
	lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>,
	virtualization <virtualization@lists.linux-foundation.org>,
	Andi Kleen <ak@muc.de>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH] Move KVM, paravirt, lguest, VMI and Xen under	arch-level Virtualization option
Date: Thu, 19 Jul 2007 23:10:54 -0700	[thread overview]
Message-ID: <46A051EE.7060304@vmware.com> (raw)
In-Reply-To: <1184911347.10380.274.camel@localhost.localdomain>

Rusty Russell wrote:
>> Otherwise we end up with $NARCH copies of that Kconfig, each slightly
>> different.  The top-level entry can be made to depend on the archs that
>> actually have some virt capability, so as not to show empty an menu.
>>     
>
> I dislike the duplication, too, but 
>
> 1) it's a CPU capability, and that's where it belongs in the menu.
> 2) And as you can see from the difference between the x86_64 and i386
> help text, there are real platform differences (and not mentioning
> what's under the menu would be kinda cheating).
> 3) Virtualization doesn't even make sense as an option for some
> platforms where it's always on.
>   

I'm rather indifferent on the matter, but I think a virtualization menu 
under UML would be very confusing.

Zach

WARNING: multiple messages have this Message-ID (diff)
From: Zachary Amsden <zach@vmware.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Avi Kivity <avi@qumranet.com>,
	lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andi Kleen <ak@muc.de>, Jeremy Fitzhardinge <jeremy@goop.org>,
	virtualization <virtualization@lists.linux-foundation.org>,
	Jeff Dike <jdike@addtoit.com>
Subject: Re: [PATCH] Move KVM, paravirt, lguest, VMI and Xen under	arch-level Virtualization option
Date: Thu, 19 Jul 2007 23:10:54 -0700	[thread overview]
Message-ID: <46A051EE.7060304@vmware.com> (raw)
In-Reply-To: <1184911347.10380.274.camel@localhost.localdomain>

Rusty Russell wrote:
>> Otherwise we end up with $NARCH copies of that Kconfig, each slightly
>> different.  The top-level entry can be made to depend on the archs that
>> actually have some virt capability, so as not to show empty an menu.
>>     
>
> I dislike the duplication, too, but 
>
> 1) it's a CPU capability, and that's where it belongs in the menu.
> 2) And as you can see from the difference between the x86_64 and i386
> help text, there are real platform differences (and not mentioning
> what's under the menu would be kinda cheating).
> 3) Virtualization doesn't even make sense as an option for some
> platforms where it's always on.
>   

I'm rather indifferent on the matter, but I think a virtualization menu 
under UML would be very confusing.

Zach

  reply	other threads:[~2007-07-20  6:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-20  4:22 [PATCH] Move KVM, paravirt, lguest, VMI and Xen under arch-level Virtualization option Rusty Russell
2007-07-20  4:31 ` Alexey Eremenko
2007-07-20  4:31 ` Alexey Eremenko
2007-07-20  5:24 ` Avi Kivity
2007-07-20  5:24 ` Avi Kivity
2007-07-20  6:02   ` Rusty Russell
2007-07-20  6:02   ` Rusty Russell
2007-07-20  6:10     ` Zachary Amsden [this message]
2007-07-20  6:10       ` Zachary Amsden
2007-07-20 14:09       ` Jeff Dike
2007-07-20 14:09         ` Jeff Dike
2007-07-21 15:49 ` Jan Engelhardt
2007-07-23  5:09   ` Rusty Russell
2007-07-23  5:09   ` Rusty Russell
2007-07-21 15:49 ` Jan Engelhardt
  -- strict thread matches above, loose matches on Subject: below --
2007-07-20  4:22 Rusty Russell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46A051EE.7060304@vmware.com \
    --to=zach@vmware.com \
    --cc=ak@muc.de \
    --cc=jdike@addtoit.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    --cc=torvalds@linux-foundation.org \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.