From: Jeremy Fitzhardinge <jeremy@goop.org>
To: M A Young <m.a.young@durham.ac.uk>
Cc: Randy Dunlap <randy.dunlap@oracle.com>,
virtualization@lists.osdl.org, xen-devel@lists.xensource.com,
Jeremy Fitzhardinge <jeremy@xensource.com>,
Chris Wright <chrisw@sous-sol.org>
Subject: Re: [patch xen.git xen-tip/master] xen: fix xenbus frontend build
Date: Wed, 06 May 2009 15:48:52 -0700 [thread overview]
Message-ID: <4A0213D4.9020504@goop.org> (raw)
In-Reply-To: <alpine.LFD.2.00.0905062324440.22137@vega2.dur.ac.uk>
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
next prev parent reply other threads:[~2009-05-06 22:48 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2009-05-07 2:20 ` [Xen-devel] " Randy Dunlap
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A0213D4.9020504@goop.org \
--to=jeremy@goop.org \
--cc=chrisw@sous-sol.org \
--cc=jeremy@xensource.com \
--cc=m.a.young@durham.ac.uk \
--cc=randy.dunlap@oracle.com \
--cc=virtualization@lists.osdl.org \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.