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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



M A Young wrote:
> On Tue, 5 May 2009, Randy Dunlap wrote:
>
>> From: Randy Dunlap <randy.dunlap@xxxxxxxxxx>
>>
>> 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
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization

[Index of Archives]     [KVM Development]     [Libvirt Development]     [Libvirt Users]     [CentOS Virtualization]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux