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