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

Re: [Xen-devel] [PATCH v3 15/15] tools/tests: Enable xen-access on ARM

On Wed, Sep 3, 2014 at 10:27 PM, Julien Grall <julien.grall@xxxxxxxxxx> wrote:
Hello Tamas,

On 02/09/14 05:15, Tamas K Lengyel wrote:
On Mon, Sep 1, 2014 at 11:26 PM, Julien Grall <julien.grall@xxxxxxxxxx
<mailto:julien.grall@linaro.org>> wrote:
    On 01/09/14 10:22, Tamas K Lengyel wrote:

        diff --git a/tools/tests/xen-access/__Makefile
        index 65eef99..698355c 100644
        --- a/tools/tests/xen-access/__Makefile
        +++ b/tools/tests/xen-access/__Makefile

        @@ -7,9 +7,7 @@ CFLAGS += $(CFLAGS_libxenctrl)
           CFLAGS += $(CFLAGS_libxenguest)
           CFLAGS += $(CFLAGS_xeninclude)

        -TARGETS-y :=
        -TARGETS-$(CONFIG_X86) += xen-access
        -TARGETS := $(TARGETS-y)
        +TARGETS := xen-access

    I would move the definition of HAS_MEM_ACCESS from arch/*/Rules.mk
    to config/*.mk and use the defition here to build or not xen-access.

I'm not a fan of that approach. How about this:

What is the problem with this solution?

Honestly, I tried to wrap my head around what is going on in config/*.mk but it didn't really click yet. It does look more complicated to have the HAS_MEM_ACCESS in config/*.mk then in arch/*/Rules.mk..
xen-access should be compiled when Xen has HAS_MEM_ACCESS=y.
As you enabled HAS_MEM_ACCESS by default when the architecture is supported, using TARGETS-$(HAS_MEM_ACCESS) += xen-access will make the support for a new architecture easier.

Anyway, I will let the maintainers decide what is the best solution.

Of course, if that's the way to go I don't have any real arguments against it. I could use some pointers in how to go about it though.

Julien Grall

Xen-devel mailing list



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