----- Original Message -----

On Fri, 6 Jan 2012, Andrew Jones wrote:

quoted

XEN_DOM0 is a silent option that has been automatically selected
when
CONFIG_XEN is selected since 6b0661a5e6fbf. If this option was
changed
to a menu configurable option then it would only give users the
ability
to compile out about 100 kbytes of code.

I think that it is less than that because backends are not tied to
dom0
in any way, even though currently they cannot be compiled without
XEN_DOM0.
Running a network or block backend in domU is a well known
configuration.
Therefore the code compiled out only amounts to about 10K.

quoted

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 8795480..0725228 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig

@@ -78,8 +78,9 @@ config XEN_DEV_EVTCHN
 
 config XEN_BACKEND
 	bool "Backend driver support"
-	depends on XEN_DOM0
 	default y
+	depends on XEN && PCI_XEN && SWIOTLB_XEN
+	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
 	help
 	  Support for backend device drivers that provide I/O services
 	  to other virtual machines.

I think we can trimmer the dependency list here: after all backends
can
be run in unpriviledged guests as well (see driver domains).
So I think it should depend only on XEN.

Hmm.. Actually, with dependency lists in mind, I think a really messed
this patch up. I should have either had CONFIG_XEN inherit these deps,
or I should have spread them around to be required at only the specific
places they're needed, and then left the stub functions in. Neither of
those options seems like a good idea to me. We either force all XEN
guests to always have all the deps needed for an initial domain, which
is exactly the opposite of the suggestion above (trimming XEN_BACKEND
deps for driver domains), or we actually make the code messier and
more complicated with more #ifdefs, which are now neatly packaged with
XEN_DOM0.

The driver domain concept may actually be the technical need for
making XEN_DOM0 optional. If we want the ability to build a minimally
configed XEN kernel to be used as a driver domain, then it doesn't
seem like we'd want it to also be capable of running as an initial
domain, or to be forced to have all the dependencies and code of an
initial domain.

With that in mind, I propose we go back to my initial patch, relax
deps for XEN_BACKEND, and double check that each individual backend
has the appropriate minimal deps. In general, it should be a goal to
make sure most XEN options are menu selectable and that all dep lists
are minimized in order to make sure driver domains can be built with
minimal configs.

Drew

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