On Thu, Jan 12, 2012 at 05:49:57AM -0500, Andrew Jones wrote:
----- Original Message -----
quoted
On Wed, Jan 11, 2012 at 05:36:38PM +0100, Andrew Jones wrote:
quoted
When XEN_XENBUS_FRONTEND gets selected as a module it can lead to
unbootable configs. If we need it, then we should just build it in.
Hm, don't the frontends by themsevles load this module? So if you
do 'modprobe xen-pcifront' it would load this automatically?
The problem is on boot, getting it there before we need xen-blkfront.
I think it might solvable if you make sure your tooling pushes the
xenbus module into your initrd. However we've had problems with
So it seems we also need patches for dracut and initramfs here?
Or is it possible to make the modules (fb) try to load xenbus frontend
automatically? Preferrably one would do this:
modprobe xen_fbfront
which would then automatically load xenbus_module, xen_kbdfront
Better yet if udev/kudzu figured out this automtically and loaded
the modules.
Is there a mechanism to automatically have udev do all of this loading?
Let CC the Debian maintainer on this converstation as he might have
some ideas in this.
platform_pci being a module in the past, and if I'm not mistaken
Right, but that driver is not tied in with the frontends. It just
pokes at the ioport to disable QEMU HVM drivers.
that was one of the motivators for building it in (5fbdc10395cd). I
see this as a similar story.
Drew
quoted
quoted
Signed-off-by: Andrew Jones <redacted>
---
drivers/xen/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 8795480..1d24061 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -118,7 +118,7 @@ config XEN_SYS_HYPERVISOR
but will have no xen contents.
config XEN_XENBUS_FRONTEND
- tristate
+ bool
config XEN_GNTDEV
tristate "userspace grant access device driver"
--
1.7.7.5
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel