Message-ID: <47964C7A.6000609@citrix.com>
Date: Tue, 22 Jan 2008 12:05:14 -0800
From: Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>
User-Agent: Thunderbird 2.0.0.9 (X11/20071115)
MIME-Version: 1.0
To: Ingo Molnar <mingo@elte.hu>
CC: Jeremy Fitzhardinge <jeremy@goop.org>,
       Eduardo Pereira Habkost <ehabkost@redhat.com>,
       linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org,
       chrisw@sous-sol.org, anthony@codemonkey.ws, hpa@zytor.com,
       akpm@linux-foundation.org, tglx@linutronix.de, roland@redhat.com,
       ak@suse.de
Subject: Re: [PATCH 0/4] paravirt_ops-64 compile fixes
References: <1200952133-31581-1-git-send-email-ehabkost@redhat.com>	<20080122120207.GA30271@elte.hu>	<20080122123450.GU7338@blackpad> <47962E1D.2090308@goop.org> <20080122194710.GC3218@elte.hu>
In-Reply-To: <20080122194710.GC3218@elte.hu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1627
Lines: 38

Ingo Molnar wrote:
> * Jeremy Fitzhardinge <jeremy@goop.org> wrote:
>
>   
>>> Maybe should this force-paravirt mode be a kernel debugging option?
>>>       
>> No, just a plain CONFIG_PARAVIRT to turn it on and off independently 
>> of everything else.
>>     
>
> it should be a debugging option in the way that it's dependent on 
> KERNEL_DEBUG and KERNEL_EXPERIMENTAL.
>   

EXPERIMENTAL certainly, but not DEBUG.  Sure, CONFIG_PARAVIRT is 
somewhat useless if you don't also configure Xen/lguest/etc, but running 
a paravirt system on bare hardware will probably be the most common way 
a paravirt kernel gets run (a distro will always enable it and compile 
in whatever hypervisor support they want, but most people will end up 
just running it on bare hardware).  Therefore, we should try to be as 
sure as possible that PARAVIRT works well (ie, indistinguishable from 
non-PARAVIRT) on bare hardware.

> i dont think you shold worry about this - i think 64-bit guest support 
> for specific hypervisors could be added even after the merge window, if 
> it's reasonably isolated (which i'd expect it to be). It clearly cannot 
> break anything else so it's the same category as new driver or new 
> hardware support - more relaxed integration rules. Then we can remove 
> the KERNEL_DEBUG and KERNEL_EXPERIMENTAL dependency as well.

Good, I'm glad you feel that way.

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