[patch xen.git xen-tip/master] xen: fix xenbus frontend build

[patch xen.git xen-tip/master] xen: fix xenbus frontend build

[Randy Dunlap]

From: Randy Dunlap <randy.dunlap@oracle.com>

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 <randy.dunlap@oracle.com>
---
 drivers/xen/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-xyz.orig/drivers/xen/Kconfig
+++ linux-xyz/drivers/xen/Kconfig
@@ -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"

Re: [patch xen.git xen-tip/master] xen: fix xenbus frontend build

[M A Young]

On Tue, 5 May 2009, Randy Dunlap wrote:

> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> 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

Re: [patch xen.git xen-tip/master] xen: fix xenbus frontend build

[Jeremy Fitzhardinge]

M A Young wrote:
> On Tue, 5 May 2009, Randy Dunlap wrote:
>
>> From: Randy Dunlap <randy.dunlap@oracle.com>
>>
>> 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).

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

Re: [Xen-devel] [patch xen.git xen-tip/master] xen: fix xenbus frontend build

[Randy Dunlap]

M A Young wrote:
> On Tue, 5 May 2009, Randy Dunlap wrote:
> 
>> From: Randy Dunlap <randy.dunlap@oracle.com>
>>
>> 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).

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

Where did you post the patch?

thanks,
-- 
~Randy
LPC 2009, Sept. 23-25, Portland, Oregon
http://linuxplumbersconf.org/2009/