Re: [Xen-devel] [PATCH 3/4] xen kconfig: add dom0 support help text

[Andrew Jones <drjones@xxxxxxxxxx>]

----- Original Message -----
> On Fri, 2012-01-06 at 09:26 +0000, Andrew Jones wrote:
> > 
> > ----- Original Message -----
> > > On Fri, 2012-01-06 at 08:57 +0000, Andrew Jones wrote:
> > > > Describe dom0 support in the config menu and supply help text
> > > > for
> > > > it.
> > > 
> > > This turns a non-user visible symbol into a user visible one.
> > > Previously
> > > if Xen was enabled and the other prerequisites were met you would
> > > get
> > > dom0 support automatically -- do we really want to change that?
> > > According to 6b0661a5e6fbf it was a deliberate decision to have
> > > it
> > > this
> > > way.
> > 
> > I think it's a necessary evil in order to give users the ability to
> > compile kernels without the support. I know it doesn't make much
> > sense
> > for most users, but...
> 
> Who actually wants to do this though and why? Do you have a bug
> report
> requesting this change?
> 

No bug for it. I'll explain the motivation below.

> Almost all of the things which dom0 needs (e.g. PCI device management
> etc) is also required by a domU with passthrough enabled so the
> savings
> are really very slight.
> 
> We are talking less than 1k of code AFAICT, 319 bytes for
> arch/x86/xen/vga.o and 573 for drivers/xen/xenfs/xenstored.o plus
> whatever xen_register_gsi (a couple of dozen lines of code) adds to
> arch/x86/pci/xen.o. grep doesn't show CONFIG_XEN_DOM0 being used
> anywhere else. What savings do you see in practice from disabling
> just
> this symbol?

I completely agree that the saving are near none. The savings, however,
aren't the only reason to drive the change. It's actually the symbol
name itself. Unfortunately configs can be perceived as a contract of
support, i.e. if feature xyz is enabled in the distro's config, then
the distributor must have selected, and therefore will support, said
feature.

I didn't make this motivation clear in my initial post, because I was
hoping to spare people some eye rolling.

> 
> We need to weigh up the size change against the complexity of asking
> the
> user yet another question, I'm not convinced the question is worth it
> on
> balance.
> 

Tons of questions aren't much fun to wade through, but I guess I'm
generally for a config menu complexity that is proportional to
(and controls) the kernel complexity.

Drew

> > > 
> > > BTW, you forgot a Signed-off-by and the appropriate CCs (please
> > > use
> > > MAINTAINERS or ./scripts/get-maintainer.pl).
> > > 
> > 
> > Sorry, I'll resend properly.
> 
> I've added those CC's to this reply too.
> 
> Ian.
> 
> > 
> > Drew
> > 
> > > Ian.
> > > 
> > > > ---
> > > >  arch/x86/xen/Kconfig |    7 ++++++-
> > > >  1 files changed, 6 insertions(+), 1 deletions(-)
> > > > 
> > > > diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> > > > index 26c731a..88862d5 100644
> > > > --- a/arch/x86/xen/Kconfig
> > > > +++ b/arch/x86/xen/Kconfig
> > > > @@ -14,9 +14,14 @@ config XEN
> > > >           Xen hypervisor.
> > > >  
> > > >  config XEN_DOM0
> > > > -       def_bool y
> > > > +       bool "Xen Initial Domain (Dom0) support"
> > > > +       default y
> > > >         depends on XEN && PCI_XEN && SWIOTLB_XEN
> > > >         depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
> > > > +       help
> > > > +         This allows the kernel to be used for the initial Xen
> > > > domain,
> > > > +         Domain0. This is a privileged guest that supplies backends
> > > > +         and is used to manage the other Xen domains.
> > > >  
> > > >  # Dummy symbol since people have come to rely on the
> > > >  PRIVILEGED_GUEST
> > > >  # name in tools.
> > > 
> > > 
> > > 
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel