From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [RFC v1 0/8] xen: kconfig changes Date: Wed, 18 Feb 2015 16:54:38 -0500 Message-ID: <20150218215438.GA24992@l.oracle.com> References: <54E2ED22.7080607@suse.com> <20150218181120.GL8152@l.oracle.com> <20150218202054.GA19571@l.oracle.com> <20150218212448.GB20614@l.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YOCa3-0004X8-JX for xen-devel@lists.xenproject.org; Wed, 18 Feb 2015 21:54:51 +0000 Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Luis R. Rodriguez" Cc: Juergen Gross , xen-devel@lists.xenproject.org, Boris Ostrovsky , David Vrabel List-Id: xen-devel@lists.xenproject.org On Wed, Feb 18, 2015 at 01:31:15PM -0800, Luis R. Rodriguez wrote: > On Wed, Feb 18, 2015 at 1:24 PM, Konrad Rzeszutek Wilk > wrote: > > On Wed, Feb 18, 2015 at 01:11:57PM -0800, Luis R. Rodriguez wrote: > >> On Wed, Feb 18, 2015 at 12:20 PM, Konrad Rzeszutek Wilk > >> wrote: > >> > On Wed, Feb 18, 2015 at 12:01:43PM -0800, Luis R. Rodriguez wrote: > >> >> On Wed, Feb 18, 2015 at 10:11 AM, Konrad Rzeszutek Wilk > >> >> wrote: > >> >> > On Tue, Feb 17, 2015 at 11:31:08AM -0800, Luis R. Rodriguez wrote: > >> >> >> On Mon, Feb 16, 2015 at 11:26 PM, Juergen Gross wrote: > >> >> >> > On 02/17/2015 01:25 AM, Luis R. Rodriguez wrote: > >> >> >> >> > >> >> >> >> On Mon, Feb 16, 2015 at 4:20 PM, Luis R. Rodriguez > >> >> >> >> wrote: > >> >> >> >>> > >> >> >> >>> As it is per our agreed upon changes we can in theory enable a > >> >> >> >>> XEN_PVHVM system without XEN_PV or XEN_PVH. If this is indeed > >> >> >> >>> desirable this poses an issue at build time > >> >> >> >> > >> >> >> >> > >> >> >> >> And this also raises the question of whether or not we should make > >> >> >> >> XEN_PVHVM a user selectable option, right now it is a def_bool and is > >> >> >> >> therefore not human selectable. You can implicitly disable it by > >> >> >> >> disabling PCI for example though. If we want that to be exposed to the > >> >> >> >> user we can then enable some description of what that means, and the > >> >> >> >> user will then be able to read / select / enable XEN_PV., XEN_PVHVM, > >> >> >> >> XEN_PVH. Right now they'd only be able to select XEN_PV and/or > >> >> >> >> XEN_PVH, XEN_PVHVM is implicit. > >> >> >> > > >> >> >> > > >> >> >> > I think making XEN_PVHVM user selectable is okay. > >> >> >> > >> >> >> OK I'll enable this then. > >> >> > > >> >> > Please don't. We had bugs in the past because distros did not select > >> >> > it (they made it an module) and the PV drivers were not loaded. > >> >> > >> >> Oy vey. > >> >> > >> >> > There should be an history in the git tree behind the desire to make > >> >> > it non selectable. > >> >> > >> >> OK how about we enable the user selection only under CONFIG_EXPERT, > >> >> otherwise make it hidden. > >> > > >> > The CONFIG_EXPERT is gone from the kernel.. > >> > >> I see it as of next-20150218, is there a proposal to remove it? > > > > I am misremembering what was . AH, http://lwn.net/Articles/421304/ > > CONFIG_EMBEDDED! > > > > Sorry about the noise. > > So whatyda think? If that is not enough to prevent *stupid* from doing > something dumb by adding own CONFIG_XEN_BUILD_EXPERT which will depend > on EXPERT but default to n. That will prevent folks that typically > enable EXPERT from going on venturing to disable what is visible > unless they *really* want it. I can't think of a reason somebody would want this disabled - they already have enabled CONFIG_HYPERVISOR so obviously they want PV drivers. And if one really really wants the PV drivers disabled there is an boot line command to disable it all. > > Luis