Skip to contentSkip to conversation

xen: fix xenbus frontend build

PATCH In review Randy Dunlap 3 participants 4 messages May 5, 2009 – May 7, 2009

Subsystems (2)
virtio core Xen hypervisor interface
lore
Share & tools
lore

Randy Dunlap

author
#0 lore raw

PATCH 1/1 xen: fix xenbus frontend build

From: Randy Dunlap <[email protected]>

When a driver kconfig symbol =m and it selects another symbol, that other symbol will also be =m (unless something else causes it to be =y), so when XEN_BLKDEV_FRONTEND=m and/or XEN_NETDEV_FRONTEND=m, then XEN_XENBUS_FRONTEND=m, but that won't build (build error message below). Changing XEN_XENBUS_FRONTEND from a tristate to a bool makes it be =y (builtin) any time that it is selected, so there is no build error.

arch/x86/pci/built-in.o: In function `xenbus_register_frontend':
include/xen/xenbus.h:115: undefined reference to `__xenbus_register_frontend'

OTOH, I could have goofed my git trees somehow...

Signed-off-by Randy Dunlap <[email protected]>
---
 drivers/xen/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/xen/Kconfig +1 -1
@@ -85,7 +85,7 @@ config XEN_SYS_HYPERVISOR
 	 but will have no xen contents.
 
 config XEN_XENBUS_FRONTEND
-       tristate
+       bool
 
 config XEN_GNTDEV
 	bool "userspace grant access device driver"
#1 lore raw
Quoted 10 lines · Randy Dunlap

From: Randy Dunlap <[email protected]>

When a driver kconfig symbol =m and it selects another symbol, that other symbol will also be =m (unless something else causes it to be =y), so when XEN_BLKDEV_FRONTEND=m and/or XEN_NETDEV_FRONTEND=m, then XEN_XENBUS_FRONTEND=m, but that won't build (build error message below). Changing XEN_XENBUS_FRONTEND from a tristate to a bool makes it be =y (builtin) any time that it is selected, so there is no build error.

That isn't the right solution. The real problem is that something you have selected as "y" does depend on XEN_XENBUS_FRONTEND but doesn't select it. Switching XEN_XENBUS_FRONTEND from tristate to bool might fix your particular compile problem, but it means that the situation you would get if you changed your configuration so that XEN_BLKDEV_FRONTEND=n and XEN_NETDEV_FRONTEND=n (likewise any other options that do select XEN_XENBUS_FRONTEND) would still broken because then XEN_XENBUS_FRONTEND won't be selected at all.

If your configuration has XEN_PCI_PASSTHROUGH=y then I posted a patch for this very situation a few days ago (and it is now in xen-tip/next, though wasn't yet in xen-tip/master when I last checked).

Michael Young

#2 lore raw
Quoted 13 lines · M A Young
Quoted 10 lines · Randy Dunlap

From: Randy Dunlap <[email protected]>

When a driver kconfig symbol =m and it selects another symbol, that other symbol will also be =m (unless something else causes it to be =y), so when XEN_BLKDEV_FRONTEND=m and/or XEN_NETDEV_FRONTEND=m, then XEN_XENBUS_FRONTEND=m, but that won't build (build error message below). Changing XEN_XENBUS_FRONTEND from a tristate to a bool makes it be =y (builtin) any time that it is selected, so there is no build error.

Quoted 3 lines

That isn't the right solution. The real problem is that something you have selected as "y" does depend on XEN_XENBUS_FRONTEND but doesn't select it. Switching XEN_XENBUS_FRONTEND from tristate to bool might fix your particular compile problem, but it means that the situation you would get if you changed your configuration so that XEN_BLKDEV_FRONTEND=n and XEN_NETDEV_FRONTEND=n (likewise any other options that do select XEN_XENBUS_FRONTEND) would still broken because then XEN_XENBUS_FRONTEND won't be selected at all.

If your configuration has XEN_PCI_PASSTHROUGH=y then I posted a patch for this very situation a few days ago (and it is now in xen-tip/next, though wasn't yet in xen-tip/master when I last checked).

pcifront wasn't meant to go into master yet. I'd be interested in some testing feedback from next.

These xenbus config options seem to be in a bit of a mess, and it would be nice if someone could go through and make them sane. I think the ideal outcome should be:

* the backend and frontend should be independently modular
* they should be independently selectable (in principle we should allow a backend-only kernel, which I don't think is possible atm)
* rather than having separate configs for frontends and backends, and a config frontend/backend xenbus, why not make the drivers depend on their appropriate xenbus, and directly configure them?

Anyone?
J

author
#3 lore raw
In reply to M A Young
Quoted 22 lines · M A Young
Quoted 10 lines · Randy Dunlap

From: Randy Dunlap <[email protected]>

When a driver kconfig symbol =m and it selects another symbol, that other symbol will also be =m (unless something else causes it to be =y), so when XEN_BLKDEV_FRONTEND=m and/or XEN_NETDEV_FRONTEND=m, then XEN_XENBUS_FRONTEND=m, but that won't build (build error message below). Changing XEN_XENBUS_FRONTEND from a tristate to a bool makes it be =y (builtin) any time that it is selected, so there is no build error.

That isn't the right solution. The real problem is that something you have selected as "y" does depend on XEN_XENBUS_FRONTEND but doesn't select it. Switching XEN_XENBUS_FRONTEND from tristate to bool might fix your particular compile problem, but it means that the situation you would get if you changed your configuration so that XEN_BLKDEV_FRONTEND=n and XEN_NETDEV_FRONTEND=n (likewise any other options that do select XEN_XENBUS_FRONTEND) would still broken because then XEN_XENBUS_FRONTEND won't be selected at all.

Quoted 3 lines

If your configuration has XEN_PCI_PASSTHROUGH=y then I posted a patch for this very situation a few days ago (and it is now in xen-tip/next, though wasn't yet in xen-tip/master when I last checked).

fwiw, yes, XEN_PCI_PASSTHROUGH=y in my .config file.

Where did you post the patch?

thanks,

Signature · 3 lines
~Randy
LPC 2009, Sept. 23-25, Portland, Oregon
http://linuxplumbersconf.org/2009/