* [patch xen.git xen-tip/master] xen: fix xenbus frontend build
@ 2009-05-05 18:42 Randy Dunlap
2009-05-06 22:38 ` M A Young
0 siblings, 1 reply; 4+ messages in thread
From: Randy Dunlap @ 2009-05-05 18:42 UTC (permalink / raw)
To: virtualization, xen-devel; +Cc: Chris Wright
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"
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [patch xen.git xen-tip/master] xen: fix xenbus frontend build
2009-05-05 18:42 [patch xen.git xen-tip/master] xen: fix xenbus frontend build Randy Dunlap
@ 2009-05-06 22:38 ` M A Young
2009-05-06 22:48 ` Jeremy Fitzhardinge
2009-05-07 2:20 ` [Xen-devel] " Randy Dunlap
0 siblings, 2 replies; 4+ messages in thread
From: M A Young @ 2009-05-06 22:38 UTC (permalink / raw)
To: Randy Dunlap
Cc: Chris Wright, virtualization, jeremy, xen-devel, Jeremy Fitzhardinge
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [patch xen.git xen-tip/master] xen: fix xenbus frontend build
2009-05-06 22:38 ` M A Young
@ 2009-05-06 22:48 ` Jeremy Fitzhardinge
2009-05-07 2:20 ` [Xen-devel] " Randy Dunlap
1 sibling, 0 replies; 4+ messages in thread
From: Jeremy Fitzhardinge @ 2009-05-06 22:48 UTC (permalink / raw)
To: M A Young
Cc: Randy Dunlap, virtualization, xen-devel, Jeremy Fitzhardinge,
Chris Wright
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Xen-devel] [patch xen.git xen-tip/master] xen: fix xenbus frontend build
2009-05-06 22:38 ` M A Young
2009-05-06 22:48 ` Jeremy Fitzhardinge
@ 2009-05-07 2:20 ` Randy Dunlap
1 sibling, 0 replies; 4+ messages in thread
From: Randy Dunlap @ 2009-05-07 2:20 UTC (permalink / raw)
To: M A Young; +Cc: Chris Wright, virtualization, xen-devel
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/
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-05-07 2:20 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-05-05 18:42 [patch xen.git xen-tip/master] xen: fix xenbus frontend build Randy Dunlap
2009-05-06 22:38 ` M A Young
2009-05-06 22:48 ` Jeremy Fitzhardinge
2009-05-07 2:20 ` [Xen-devel] " Randy Dunlap
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.