Message-ID: <20130709144840.GF24897@phenom.dumpdata.com>
Date:	Tue, 9 Jul 2013 10:48:40 -0400
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	Jan Beulich <JBeulich@...e.com>
Cc:	Borislav Petkov <bp@...en8.de>, Matt Wilson <msw@...zon.com>,
	Michael Opdenacker <michael.opdenacker@...e-electrons.com>,
	jeremy@...p.org, x86@...nel.org, tglx@...utronix.de,
	virtualization@...ts.linux-foundation.org,
	xen-devel@...ts.xensource.com, mingo@...hat.com,
	Paul Bolle <pebolle@...cali.nl>, linux-kernel@...r.kernel.org,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [Xen-devel] [PATCH] xen: remove unused Kconfig parameter

On Tue, Jul 09, 2013 at 08:41:12AM +0100, Jan Beulich wrote:
> >>> On 09.07.13 at 02:26, Konrad Rzeszutek Wilk <konrad.wilk@...cle.com> wrote:
> > Could you explain to me please why the check in the scripts is superfluous?
> 
> This is not really the question - _any_ such check can only be
> wrong. The boot loader has absolutely no business caring about
> kernel internals, and the kernel shouldn't be limited by it in how it
> renames/adds/deletes Kconfig options and anything else.

Then that should be discussed on grub2 to remove said check and modify
the code so that it can properly work without regression.

> 
> > Especially as the grand plan is to get rid of CONFIG_XEN_DOM0 and more or 
> > less have a backend and fronted config option (since that makes more sense 
> > nowadays). And that would make the XEN_DOM0 be obsolete and the XEN_PRIV 
> > would be the one that turns a lot of the options needed to compile a kernel 
> > that can provide backend driver support. (I am hand waving here). 
> 
> That's pretty odd a plan, considering that Dom0 is more than just
> an environment to provide backends. In fact, Dom0 may not be
> providing any backends at all, and instead just serve the
> "controlling hardware" and/or "control domain" purpose that it
> really is meant to be. But of course, if none of _that_ functionality
> depends on this config option, then it indeed could go away.

Right, if I follow that train of logic then there is the 'controlling
domain' and 'hardware backend domain' and then the rest - the guests.

The 'controlling domain' would be just the one that is priviliged to launch
guests, setup the proper XSM labels, etc. Nothing to do with hardware.
But everything to deal with the toolstack.

The 'hardware backend domain' on the other hand has drivers and it also
needs a mechanism to export said devices to the guests. Otherwise it is
a pretty poor 'backend domain' without any way to export the devices
to guests.

Dom0 has been both - but there is nothing wrong with seperating these
two labels. And therein I was thinking that the 'hardware backend domain'
should be the introduced. I am not good with names so the best option
seems CONFIG_XEN_PRIVILIGED, but that sounds to be like 'controlling domain'.

Any good ideas for names? CONFIG_XEN_HARDWARE_DOMAIN ? CONFIG_XEN_PRIVILIGED_DOMAIN?

The items that would depend on CONFIG_XEN_PRIVILIGED_DOMAIN would be
the gntdev.c, xenfs.c and evtchn.c ?

The CONFIG_XEN_HARDWARE_DOMAIN would be mostly everything else - and
also require support for ACPI, PCI, SMP - the low-level thing, and
then the backends.

Lastly the guests. They should be able to be compiled and run without
setting either one of those two options (thought if one wants to set
them that is fine).

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

Powered by blists - more mailing lists