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

Re: [Xen-devel] [RFC v1 0/8] xen: kconfig changes

On Wed, Feb 18, 2015 at 2:12 AM, Juergen Gross <jgross@xxxxxxxx> wrote:
> On 02/18/2015 11:03 AM, David Vrabel wrote:
>> On 17/02/15 07:39, Juergen Gross wrote:
>>> If we have neither XEN_PV nor XEN_PVH set, why do we have to build
>>> enlighten.c? It will never be used. Same should apply to several other
>>> files in arch/x86/xen.
>> Can we limit this series to only Kconfig changes?  I don't really like
>> scope-creep in patch series.
> Are you sure this is possible?

I do not think so. We can only do the smaller cleanups, the frontend
stuff and the backend stuff however will remain constrained due to
existing relationships being assumed under the big CONFIG_XEN. More
details on this below.

> XEN will be configured in more cases as
> today: this is the result of being able to build pv-drivers for hvm
> domains.
> BTW: it was you who wanted XEN_PVHVM to be implying XEN.
> So today the complete directory arch/x86/xen isn't built for non-pv
> kernels. Do you really want to change this? I don't think this is
> acceptable.

A simple issue example to think about:

The arch/x86/kernel/head_[64|32].S file includes
arch/x86/xen/xen-head.S. Now this file is #ifdef's over CONFIG_XEN. As
per our agreed upon changes the frontend drivers depend on CONFIG_XEN
but without CONFIG_XEN_PV and CONFIG_XEN_PVH this won't build
correctly after the other changes we've discussed.

What I can do, if folks like, is to pursue the split only as expected
RFCs only as evaluation just to get a better idea of what changes are
really required for what we discussed, I am not sure the required code
changes had been scoped out before.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.