Re: [Xen-devel] [RFC v1 0/8] xen: kconfig changes

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

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
> <konrad.wilk@xxxxxxxxxx> 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
> >> <konrad.wilk@xxxxxxxxxx> 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
> >> >> <konrad.wilk@xxxxxxxxxx> 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 <jgross@xxxxxxxx> 
> >> >> >> wrote:
> >> >> >> > On 02/17/2015 01:25 AM, Luis R. Rodriguez wrote:
> >> >> >> >>
> >> >> >> >> On Mon, Feb 16, 2015 at 4:20 PM, Luis R. Rodriguez
> >> >> >> >> <mcgrof@xxxxxxxxxxxxxxxx> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel