from:"Alistair Francis"

Re: [Xen-devel] [Qemu-devel] [PATCH v3 01/46] Replace all occurances of FUNCTION with func

2017-11-08 Thread Alistair Francis

On Wed, Nov 8, 2017 at 7:00 AM, Eric Blake <ebl...@redhat.com> wrote:
> On 11/08/2017 08:51 AM, Alistair Francis wrote:
>
>>>>> Let me rephrase the question: do we really support compilers that don't
>>>>> understand __func__?  The presence of numerous unconditional uses of
>>>>> __func__ in the tree means the answer is no.  Let's replace AUDIO_FUNC
>>>>> by plain __func__.
>>>>
>>>> Answered elsewhere in patch 3/46 (where we DO replace AUDIO_FUNC by
>>>> __func__).
>>>
>>> I see.
>>>
>>> Put 03/46 first, so we don't have to mess with AUDIO_FUNC twice?
>>
>> I would really like to avoid that, as the conflicts will be a bit of a
>> mess. The way I see it there will be a lot of churn no matter what,
>> so we don't gain much by swapping the order around.
>>
>> I have a new series ready to send today, so I'm going to send that
>> through as I would like at least some of these patches to make it in
>> 2.11. After that if you think strongly the order should be changed I
>> can change it in the next version.
>
> I think the reorder is not that hard.  Put 3/46 first (changing
> AUDIO_FUNC to __func__), and then 1/46 doesn't have to touch any of the
> files that used to use AUDIO_FUNC, because there is no intermediate
> state using __FUNCTION__.
>
> If I'm reading it correctly, the rebase conflict is limited to a slight
> rewording of the commit message for 3/46, and one line in 1/46 to the
> definition of AUDIO_FUNC (that will no longer be present).

That's true, it didn't end up being that hard. I'm launching my tests
now, so I should be able to send the series out later today.

Hopefully some of this can make it in 2.11 :)

Thanks,
Alistair

>
> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.   +1-919-301-3266
> Virtualization:  qemu.org | libvirt.org
>

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [Qemu-devel] [PATCH v3 01/46] Replace all occurances of FUNCTION with func

2017-11-08 Thread Alistair Francis

On Tue, Nov 7, 2017 at 11:52 PM, Markus Armbruster <arm...@redhat.com> wrote:
> Eric Blake <ebl...@redhat.com> writes:
>
>> On 11/07/2017 04:12 AM, Markus Armbruster wrote:
>>> Juan Quintela <quint...@redhat.com> writes:
>>>
>>>> Alistair Francis <alistair.fran...@xilinx.com> wrote:
>>>>> Replace all occurs of __FUNCTION__ except for the check in checkpatch
>>>>> with the non GCC specific __func__.
>>>>>
>>
>>>>> +++ b/audio/audio_int.h
>>>>> @@ -253,7 +253,7 @@ static inline int audio_ring_dist (int dst, int src, 
>>>>> int len)
>>>>>  #define AUDIO_STRINGIFY(n) AUDIO_STRINGIFY_(n)
>>>>>
>>>>>  #if defined _MSC_VER || defined __GNUC__
>>>>> -#define AUDIO_FUNC __FUNCTION__
>>>>> +#define AUDIO_FUNC __func__
>>>>>  #else
>>>>>  #define AUDIO_FUNC __FILE__ ":" AUDIO_STRINGIFY (__LINE__)
>>>>>  #endif
>>>>
>>>> Unrelated to this patch 
>>>> Do we really support other compilers than msc and gcc?
>>>
>>> Let me rephrase the question: do we really support compilers that don't
>>> understand __func__?  The presence of numerous unconditional uses of
>>> __func__ in the tree means the answer is no.  Let's replace AUDIO_FUNC
>>> by plain __func__.
>>
>> Answered elsewhere in patch 3/46 (where we DO replace AUDIO_FUNC by
>> __func__).
>
> I see.
>
> Put 03/46 first, so we don't have to mess with AUDIO_FUNC twice?

I would really like to avoid that, as the conflicts will be a bit of a
mess. The way I see it there will be a lot of churn no matter what,
so we don't gain much by swapping the order around.

I have a new series ready to send today, so I'm going to send that
through as I would like at least some of these patches to make it in
2.11. After that if you think strongly the order should be changed I
can change it in the next version.

Thanks,
Alistair

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [Qemu-arm] [Qemu-devel] [PATCH v1 1/8] Replace all occurances of FUNCTION with func

2017-09-28 Thread Alistair Francis

On Wed, Sep 27, 2017 at 4:47 PM, Peter Maydell <peter.mayd...@linaro.org> wrote:
> On 26 September 2017 at 06:32, Eric Blake <ebl...@redhat.com> wrote:
>> On 09/25/2017 07:08 PM, Alistair Francis wrote:
>>> diff --git a/hw/arm/nseries.c b/hw/arm/nseries.c
>>> index 58005b6619..32687afced 100644
>>> --- a/hw/arm/nseries.c
>>> +++ b/hw/arm/nseries.c
>>> @@ -463,7 +463,7 @@ static uint32_t mipid_txrx(void *opaque, uint32_t cmd, 
>>> int len)
>>>  uint8_t ret;
>>>
>>>  if (len > 9) {
>>> -hw_error("%s: FIXME: bad SPI word width %i\n", __FUNCTION__, len);
>>> +hw_error("%s: FIXME: bad SPI word width %i\n", __func__, len);
>>
>> Not this patch's problem, but it would probably be simpler if hw_error()
>> were a macro that automatically prefixed __func__, rather than making
>> every caller have to supply it themselves.
>
> I'm not sure there's a great deal of benefit to that change, because
> use of hw_error() in new code is rarely correct (it does an abort()
> so it should never be used for guest-triggered conditions, which is
> about the only time that you might be interested in a guest register
> dump rather than just asserting). Most of its existing uses are in
> crufty old device models.

Ok, another excuse to leave it out :)

Thanks,
Alistair

>
> thanks
> -- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [Qemu-devel] [PATCH v1 1/8] Replace all occurances of FUNCTION with func

2017-09-27 Thread Alistair Francis

On Tue, Sep 26, 2017 at 6:32 AM, Eric Blake <ebl...@redhat.com> wrote:
> On 09/25/2017 07:08 PM, Alistair Francis wrote:
>> Replace all occurs of __FUNCTION__ except for the check in checkpatch
>> with the non GCC specific __func__.
>>
>> One line in hcd-musb.c was manually tweaked to pass checkpatch.
>>
>> Signed-off-by: Alistair Francis <alistair.fran...@xilinx.com>
>> Cc: Gerd Hoffmann <kra...@redhat.com>
>> Cc: Andrzej Zaborowski <balr...@gmail.com>
>> Cc: Stefano Stabellini <sstabell...@kernel.org>
>> Cc: Anthony Perard <anthony.per...@citrix.com>
>> Cc: John Snow <js...@redhat.com>
>> Cc: Aurelien Jarno <aurel...@aurel32.net>
>> Cc: Yongbok Kim <yongbok@imgtec.com>
>> Cc: Peter Crosthwaite <crosthwaite.pe...@gmail.com>
>> Cc: Stefan Hajnoczi <stefa...@redhat.com> (supporter:Block
>> Cc: Fam Zheng <f...@redhat.com> (supporter:Block
>
> That looks funny, with no closing ).  Something's breaking down between
> get_maintainers.pl and your eventual email, although it's not fatal.

Yeah, that's a copy and paste error, will fix.

>
>> Cc: Juan Quintela <quint...@redhat.com>
>> Cc: "Dr. David Alan Gilbert" <dgilb...@redhat.com>
>> Cc: qemu-...@nongnu.org
>> Cc: qemu-bl...@nongnu.org
>> Cc: xen-de...@lists.xenproject.org
>> ---
>>
>
>>  65 files changed, 273 insertions(+), 273 deletions(-)
>
> Big but mechanical, so I'm okay without splitting it further.

Phew! I did not want to split it.

>
>>
>> diff --git a/audio/audio_int.h b/audio/audio_int.h
>> index 5bcb1c60e1..543b1bd8d5 100644
>> --- a/audio/audio_int.h
>> +++ b/audio/audio_int.h
>> @@ -253,7 +253,7 @@ static inline int audio_ring_dist (int dst, int src, int 
>> len)
>>  #define AUDIO_STRINGIFY(n) AUDIO_STRINGIFY_(n)
>>
>>  #if defined _MSC_VER || defined __GNUC__
>> -#define AUDIO_FUNC __FUNCTION__
>> +#define AUDIO_FUNC __func__
>>  #else
>>  #define AUDIO_FUNC __FILE__ ":" AUDIO_STRINGIFY (__LINE__)
>>  #endif
>
> This can be further simplified.  We really aren't using _MSC_VER as our
> compiler (can anyone prove me wrong?), and we DO require a C99 compiler
> (per C99 6.4.2.2, __func__ support is mandatory), so we don't really
> need the #else branch (or, for that matter, we probably don't even need
> AUDIO_FUNC).  But to keep this patch mechanical, that can be a separate
> followup.

I have a second patch that removes AUDIO_FUNC

>
>> diff --git a/hw/arm/nseries.c b/hw/arm/nseries.c
>> index 58005b6619..32687afced 100644
>> --- a/hw/arm/nseries.c
>> +++ b/hw/arm/nseries.c
>> @@ -463,7 +463,7 @@ static uint32_t mipid_txrx(void *opaque, uint32_t cmd, 
>> int len)
>>  uint8_t ret;
>>
>>  if (len > 9) {
>> -hw_error("%s: FIXME: bad SPI word width %i\n", __FUNCTION__, len);
>> +hw_error("%s: FIXME: bad SPI word width %i\n", __func__, len);
>
> Not this patch's problem, but it would probably be simpler if hw_error()
> were a macro that automatically prefixed __func__, rather than making
> every caller have to supply it themselves.

I'm going to leave this for another day, but I think you are right.

>
>> +++ b/hw/arm/omap1.c
>
>> @@ -1716,7 +1716,7 @@ static void omap_clkm_write(void *opaque, hwaddr addr,
>>  case 0x18:   /* ARM_SYSST */
>>  if ((s->clkm.clocking_scheme ^ (value >> 11)) & 7) {
>>  s->clkm.clocking_scheme = (value >> 11) & 7;
>> -printf("%s: clocking scheme set to %s\n", __FUNCTION__,
>> +printf("%s: clocking scheme set to %s\n", __func__,
>>  clkschemename[s->clkm.clocking_scheme]);
>
> Worth fixing the indentation while you are here?

Fixed

>
>> @@ -2473,7 +2473,7 @@ static void omap_pwt_write(void *opaque, hwaddr addr,
>>  case 0x04:   /* VRC */
>>  if ((value ^ s->vrc) & 1) {
>>  if (value & 1)
>> -printf("%s: %iHz buzz on\n", __FUNCTION__, (int)
>> +printf("%s: %iHz buzz on\n", __func__, (int)
>>  /* 1.5 MHz from a 12-MHz or 13-MHz PWT_CLK 
>> */
>>  ((omap_clk_getrate(s->clk) >> 3) /
>>   /* Pre-multiplexer divider */
>
> Likewise?

This doesn't actually change the indention. It's all one argument to a function.

>
>> @@ -3330,13 +3330,13 @@ static void omap_mcbsp

Re: [Xen-devel] [Qemu-devel] [PATCH v1 3/8] hw: Replace fprintf(stderr, "*\n" with error_report()

2017-09-27 Thread Alistair Francis

On Mon, Sep 25, 2017 at 8:51 PM, Thomas Huth <h...@tuxfamily.org> wrote:
> On 26.09.2017 02:08, Alistair Francis wrote:
>> Replace a large number of the fprintf(stderr, "*\n" calls with
>> error_report(). The functions were renamed with these commands and then
>> compiler issues where manually fixed.
>>
>> find ./* -type f -exec sed -i \
>> 'N;N;N;N;N;N;N;N;N;N;N;N; {s|fprintf(stderr, 
>> "\(.*\)\\n"\(.*\));|error_report("\1"\2);|Ig}' \
>> {} +
>> find ./* -type f -exec sed -i \
>> 'N;N;N;N;N;N;N;N;N;N;N; {s|fprintf(stderr, 
>> "\(.*\)\\n"\(.*\));|error_report("\1"\2);|Ig}' \
>> {} +
>> find ./* -type f -exec sed -i \
>> 'N;N;N;N;N;N;N;N;N; {s|fprintf(stderr, 
>> "\(.*\)\\n"\(.*\));|error_report("\1"\2);|Ig}' \
>> {} +
>> find ./* -type f -exec sed -i \
>> 'N;N;N;N;N;N;N;N; {s|fprintf(stderr, 
>> "\(.*\)\\n"\(.*\));|error_report("\1"\2);|Ig}' \
>> {} +
>> find ./* -type f -exec sed -i \
>> 'N;N;N;N;N;N;N; {s|fprintf(stderr, 
>> "\(.*\)\\n"\(.*\));|error_report("\1"\2);|Ig}' \
>> {} +
>> find ./* -type f -exec sed -i \
>> 'N;N;N;N;N;N; {s|fprintf(stderr, 
>> "\(.*\)\\n"\(.*\));|error_report("\1"\2);|Ig}' \
>> {} +
>> find ./* -type f -exec sed -i \
>> 'N;N;N;N;N; {s|fprintf(stderr, 
>> "\(.*\)\\n"\(.*\));|error_report("\1"\2);|Ig}' \
>> {} +
>> find ./* -type f -exec sed -i \
>> 'N;N;N;N; {s|fprintf(stderr, 
>> "\(.*\)\\n"\(.*\));|error_report("\1"\2);|Ig}' \
>> {} +
>> find ./* -type f -exec sed -i \
>> 'N;N;N; {s|fprintf(stderr, 
>> "\(.*\)\\n"\(.*\));|error_report("\1"\2);|Ig}' \
>> {} +
>> find ./* -type f -exec sed -i \
>> 'N;N; {s|fprintf(stderr, "\(.*\)\\n"\(.*\));|error_report("\1"\2);|Ig}' \
>> {} +
>> find ./* -type f -exec sed -i \
>> 'N; {s|fprintf(stderr, "\(.*\)\\n"\(.*\));|error_report("\1"\2);|Ig}' \
>> {} +
>>
>> Some lines where then manually tweaked to pass checkpatch.
>>
>> Signed-off-by: Alistair Francis <alistair.fran...@xilinx.com>
>> Cc: Andrzej Zaborowski <balr...@gmail.com>
>> Cc: Jan Kiszka <jan.kis...@web.de>
>> Cc: Stefan Hajnoczi <stefa...@redhat.com>
>> Cc: Paolo Bonzini <pbonz...@redhat.com>
>> Cc: Thomas Huth <h...@tuxfamily.org>
>> Cc: Gerd Hoffmann <kra...@redhat.com>
>> Cc: "Michael S. Tsirkin" <m...@redhat.com>
>> Cc: Richard Henderson <r...@twiddle.net>
>> Cc: Eduardo Habkost <ehabk...@redhat.com>
>> Cc: Stefano Stabellini <sstabell...@kernel.org>
>> Cc: Anthony Perard <anthony.per...@citrix.com>
>> Cc: John Snow <js...@redhat.com>
>> Cc: Christian Borntraeger <borntrae...@de.ibm.com>
>> Cc: Cornelia Huck <coh...@redhat.com>
>> Cc: Alexander Graf <ag...@suse.de>
>> Cc: Michael Walle <mich...@walle.cc>
>> Cc: Paul Burton <paul.bur...@imgtec.com>
>> Cc: Aurelien Jarno <aurel...@aurel32.net>
>> Cc: Yongbok Kim <yongbok@imgtec.com>
>> Cc: "Hervé Poussineau" <hpous...@reactos.org>
>> Cc: Anthony Green <gr...@moxielogic.com>
>> Cc: Jason Wang <jasow...@redhat.com>
>> Cc: Chris Wulff <crwu...@gmail.com>
>> Cc: Marek Vasut <ma...@denx.de>
>> Cc: Jia Liu <pro...@gmail.com>
>> Cc: Stafford Horne <sho...@gmail.com>
>> Cc: Marcel Apfelbaum <mar...@redhat.com>
>> Cc: Magnus Damm <magnus.d...@gmail.com>
>> Cc: Fabien Chouteau <chout...@adacore.com>
>> Cc: Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk>
>> Cc: Artyom Tarasenko <atar4q...@gmail.com>
>> Cc: qemu-...@nongnu.org
>> Cc: qemu-bl...@nongnu.org
>> Cc: xen-de...@lists.xenproject.org
>> Cc: qemu-...@nongnu.org
>> ---
>>
>>  hw/arm/armv7m.c |  2 +-
>>  hw/arm/boot.c   | 34 +--
>>  hw/arm/gumstix.c| 13 
>>  hw/arm/mainstone.c  |  7 ++--
>>  hw/arm/musicpal.c   |  2 +-
>>  hw/arm/omap1.c  |  5 +--
>>  hw/arm/omap2.c  | 21 ++--
>>  hw/arm/omap_sx1.c   |  6 ++--
>>  hw/arm/palm.c   | 10 +++---
>>  hw/arm/pxa2xx.c |  7 ++--
>>  hw/arm/stel

Re: [Xen-devel] [Qemu-devel] [PATCH v2] event: Add source information to SHUTDOWN

2017-04-20 Thread Alistair Francis

On Thu, Apr 20, 2017 at 12:05 PM, Eric Blake  wrote:
> On 04/20/2017 11:18 AM, Markus Armbruster wrote:
>> Eric Blake  writes:
>>
>>> On 04/20/2017 06:59 AM, Markus Armbruster wrote:
>>>

 No objection to Alistair's idea to turn this into an enumeration.
>>>
>>> Question - should the enum be more than just 'guest' and 'host'?  For
>>> example, my patch proves that we have a lot of places that handle
>>> complimentary machine commands to reset and shutdown, and that whether
>>> 'reset' triggers a reset (and the guest keeps running as if rebooted) or
>>> a shutdown is then based on the command-line arguments given to qemu.
>>> So having the enum differentiate between 'guest-reset' and
>>> 'guest-shutdown' would be a possibility, if we want the enum to have
>>> additional states.
>>
>> I don't know.  What I do know is that we better get the enum right:
>> while adding members is backwards-compatible, changing the member sent
>> for a specific trigger is not.  If we want to reserve the option to do
>> that anyway, we need suitable documentation.
>
> Or even this idea:
>
> { 'enum': 'ShutdownCause', 'data': [ 'shutdown', 'reset', 'panic' ] }
> { 'event': 'SHUTDOWN',
>   'data': { 'guest': 'bool', '*cause': 'ShutdownCause' } }
>
> where the enum can grow as we come up with ever more reasons worth
> exposing (maybe even 'qmp', 'gui' and 'interrupt' are reasonable causes
> for a host shutdown).  Our promise would be that 'guest' never changes
> for an existing shutdown reason, but that 'cause' may become more
> refined over time if someone expresses a need for having the distinction.
>
> Thoughts?

I'm not a fan of the 'guest' bool. I do see that it helps with
maintaining backwards compatibility but I think we would be better off
just getting the reasons right in the first place.

What about something that can grow in the future? We start with a
general guest shutdown that is always there and then as we add new
reasons things can be moved to use the new method or continue to use
the general one.

SHUTDOWN_HOST
SHUTDOWN_HOST_GUI
/* This is always a backwards compatible fall-back
 * Maybe this could be SHUTDOWN_GUEST_UNKNOWN instead?
 */
SHUTDOWN_GUEST_GENERAL
SHUTDOWN_GUEST_HALT
SHUTDOWN_GUEST_RESET
...

That way we can guarantee the base coverage but still expand more
specific reasons in the future.

I guess the only problem is that then the reasons aren't always
reliable then as we could introduce a new reason and something gets
stuck using the general fall back.

Thanks,

Alistair

>
> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.   +1-919-301-3266
> Virtualization:  qemu.org | libvirt.org
>

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [Qemu-devel] [PATCH v2] event: Add source information to SHUTDOWN

2017-04-19 Thread Alistair Francis

On Wed, Apr 19, 2017 at 3:22 PM, Eric Blake  wrote:
> Libvirt would like to be able to distinguish between a SHUTDOWN
> event triggered solely by guest request and one triggered by a
> SIGTERM or other action on the host.  qemu_kill_report() is
> already able to tell whether a shutdown was triggered by a host
> signal (but NOT by a host UI event, such as clicking the X on
> the window), but that information was then lost after being
> printed to stderr.
>
> Enhance the shutdown request path to take a parameter of which
> way it is being triggered, and update ALL callers.  It would have
> been less churn to keep the common case with no arguments as
> meaning guest-triggered, and only modified the host-triggered
> code paths, via a wrapper function, but then we'd still have to
> audit that I didn't miss any host-triggered spots; changing the
> signature forces us to double-check that I correctly categorized
> all callers.
>
> Here is output from 'virsh qemu-monitor-event --loop' with the
> patch installed:
>
> event SHUTDOWN at 1492639680.731251 for domain fedora_13: {"guest":true}
> event STOP at 1492639680.732116 for domain fedora_13: 
> event SHUTDOWN at 1492639680.732830 for domain fedora_13: {"guest":false}
>
> Note that libvirt runs qemu with -no-quit: the first SHUTDOWN event
> was triggered by an action I took directly in the guest (shutdown -h),
> at which point qemu stops the vcpus and waits for libvirt to do any
> final cleanups; the second SHUTDOWN event is the result of libvirt
> sending SIGTERM now that it has completed cleanup.
>
> See also https://bugzilla.redhat.com/1384007
>
> Signed-off-by: Eric Blake 
>
> ---
>
> I did not wire up the RESET event to report guest-triggered, although
> I had to plumb that through all the guests since qemu has options that
> allow remapping reset to shutdown.  It's easy to add that if we want
> it in v3.
>
> The replay driver needs a followup patch if we want to be able to
> faithfully replay the difference between a host- and guest-initiated
> shutdown (for now, the replayed event is always attributed to host).
>
>
> v2: retitle (was "event: Add signal information to SHUTDOWN"),
> completely rework to post bool based on whether it is guest-initiated
> v1: initial submission, exposing just Unix signals from host

With all this churn is it not worth chaning the bool from_guest to an
int that we can expand in future?

I'm imagining an enum with multiple values for different shutdown
events. At the moment it will just be one for guest and one for host,
but at some point in the future we might want more.

Not only does this future proof us, but I think it makes it more clear
what you are passing the function instead of just true/false.

Thanks,

Alistair

> ---
>  qapi/event.json |  8 ++--
>  include/sysemu/sysemu.h |  4 ++--
>  vl.c| 19 +++
>  hw/acpi/core.c  |  4 ++--
>  hw/arm/highbank.c   |  4 ++--
>  hw/arm/integratorcp.c   |  2 +-
>  hw/arm/musicpal.c   |  2 +-
>  hw/arm/omap1.c  |  6 +++---
>  hw/arm/omap2.c  |  2 +-
>  hw/arm/spitz.c  |  2 +-
>  hw/arm/stellaris.c  |  2 +-
>  hw/arm/tosa.c   |  2 +-
>  hw/i386/pc.c|  2 +-
>  hw/input/pckbd.c|  4 ++--
>  hw/ipmi/ipmi.c  |  4 ++--
>  hw/isa/lpc_ich9.c   |  2 +-
>  hw/mips/boston.c|  2 +-
>  hw/mips/mips_malta.c|  2 +-
>  hw/mips/mips_r4k.c  |  4 ++--
>  hw/misc/arm_sysctl.c|  8 
>  hw/misc/cbus.c  |  2 +-
>  hw/misc/macio/cuda.c|  4 ++--
>  hw/misc/slavio_misc.c   |  4 ++--
>  hw/misc/zynq_slcr.c |  2 +-
>  hw/pci-host/apb.c   |  4 ++--
>  hw/pci-host/bonito.c|  2 +-
>  hw/pci-host/piix.c  |  2 +-
>  hw/ppc/e500.c   |  2 +-
>  hw/ppc/mpc8544_guts.c   |  2 +-
>  hw/ppc/ppc.c|  2 +-
>  hw/ppc/ppc405_uc.c  |  2 +-
>  hw/ppc/spapr_hcall.c|  2 +-
>  hw/ppc/spapr_rtas.c |  4 ++--
>  hw/s390x/ipl.c  |  2 +-
>  hw/sh4/r2d.c|  2 +-
>  hw/timer/etraxfs_timer.c|  2 +-
>  hw/timer/m48t59.c   |  4 ++--
>  hw/timer/milkymist-sysctl.c |  4 ++--
>  hw/timer/pxa2xx_timer.c |  2 +-
>  hw/watchdog/watchdog.c  |  2 +-
>  hw/xenpv/xen_domainbuild.c  |  2 +-
>  hw/xtensa/xtfpga.c  |  2 +-
>  kvm-all.c   |  6 +++---
>  os-win32.c  |  2 +-
>  qmp.c   |  4 ++--
>  replay/replay.c |  5 -
>  target/alpha/sys_helper.c   |  4 ++--
>  target/arm/psci.c   |  4 ++--
>  target/i386/excp_helper.c   |  2 +-
>  target/i386/hax-all.c   |  6 +++---
>  target/i386/helper.c|  2 +-
>  target/i386/kvm.c   |  2 +-
>  target/s390x/helper.c   |  2 +-
>  target/s390x/kvm.c  |  4 ++--
>

[Xen-devel] [PATCH 1/2] tools: Use POSIX poll.h instead of sys/poll.h

2017-04-17 Thread Alistair Francis

The POSIX spec specifies to use:
#include 
instead of:
#include 
as seen here:
http://pubs.opengroup.org/onlinepubs/009695399/functions/poll.html

This removes the warning:
#warning redirecting incorrect #include  to 
when building with the musl C-library.

Signed-off-by: Alistair Francis <alistair.fran...@xilinx.com>
---
 tools/libxl/libxl_internal.h   | 2 +-
 tools/tests/xen-access/xen-access.c| 2 +-
 tools/xenstat/libxenstat/src/xenstat_qmp.c | 2 +-
 tools/xentrace/xentrace.c  | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index be24b76dfa..5d082c5704 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -38,7 +38,7 @@
 #include 
 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/tools/tests/xen-access/xen-access.c 
b/tools/tests/xen-access/xen-access.c
index ff4d289b45..238011e010 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -36,7 +36,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 #include 
diff --git a/tools/xenstat/libxenstat/src/xenstat_qmp.c 
b/tools/xenstat/libxenstat/src/xenstat_qmp.c
index a87c9373c2..3fda487d49 100644
--- a/tools/xenstat/libxenstat/src/xenstat_qmp.c
+++ b/tools/xenstat/libxenstat/src/xenstat_qmp.c
@@ -14,7 +14,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/tools/xentrace/xentrace.c b/tools/xentrace/xentrace.c
index f09fe6cf19..364a6fdad5 100644
--- a/tools/xentrace/xentrace.c
+++ b/tools/xentrace/xentrace.c
@@ -24,7 +24,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #include 
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 2/2] tools: Use POSIX signal.h instead of sys/signal.h

2017-04-17 Thread Alistair Francis

The POSIX spec specifies to use:
#include 
instead of:
#include 
as seen here:
   http://pubs.opengroup.org/onlinepubs/009695399/functions/signal.html

This removes the warning:
#warning redirecting incorrect #include  to 
when building with the musl C-library.

Signed-off-by: Alistair Francis <alistair.fran...@xilinx.com>
---
 tools/blktap2/drivers/tapdisk-server.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/blktap2/drivers/tapdisk-server.c 
b/tools/blktap2/drivers/tapdisk-server.c
index eecde3d23f..71315bb069 100644
--- a/tools/blktap2/drivers/tapdisk-server.c
+++ b/tools/blktap2/drivers/tapdisk-server.c
@@ -30,7 +30,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "tapdisk-utils.h"
 #include "tapdisk-server.h"
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking

2016-12-22 Thread Alistair Francis

On Thu, Dec 22, 2016 at 2:11 PM, Alistair Francis
<alistair.fran...@xilinx.com> wrote:
> On Thu, Dec 22, 2016 at 2:00 PM, Doug Goldstein <car...@cardoe.com> wrote:
>> On 12/22/16 3:47 PM, Andrew Cooper wrote:
>>> On 22/12/16 21:41, Alistair Francis wrote:
>>>> On Thu, Dec 22, 2016 at 1:15 PM, Alistair Francis
>>>> <alistair.fran...@xilinx.com> wrote:
>>>>> On Thu, Dec 22, 2016 at 1:12 PM, Alistair Francis
>>>>> <alistair.fran...@xilinx.com> wrote:
>>>>>> On Thu, Dec 22, 2016 at 11:22 AM, Ian Jackson
>>>>>> <ian.jack...@eu.citrix.com> wrote:
>>>>>>> Alistair Francis writes ("Re: [Xen-devel] [PATCH v2 1/5] Remove
>>>>>>> hardcoded strict -Werror checking"):
>>>>>>>> On Thu, Dec 22, 2016 at 12:41 AM, Jan Beulich <jbeul...@suse.com>
>>>>>>>> wrote:
>>>>>>>>> On 20.12.16 at 20:46, <alistair.fran...@xilinx.com> wrote:
>>>>>>>>>> Signed-off-by: Alistair Francis <alistair.fran...@xilinx.com>
>>>>>>>>> Without some rationale given I don't think such changes are
>>>>>>>>> acceptable at all. And then, as already pointed out others, the
>>>>>>>>> use of -Werror is there not just for fun. If anything I think an
>>>>>>>>> override to that default could be acceptable.
>>>>>>>> Unfortunately the APPEND_CFLAGS=-Wno-error doesn't fix all the issues
>>>>>>>> as I still see warnings/errors when building: tools/kconfig/conf.c.
>>>>>>> That sounds like a bug to me.  Do you know why it's not effective
>>>>>>> there ?
>>>>>> It actually might be an issue in the way buildroot is handling the
>>>>>> arguments.
>>>>>>
>>>>>> I'll look into it and see what I find after the holidays.
>>>> I dug into this a little more. Adding the APPEND_CFLAGS="-Wno-error"
>>>> fixes almost everything. The only problem I see is in the log below,
>>>> where tools/kconfig/conf.c fails to build as the -Wno-error doesn't
>>>> propagate down.
>>>>
>>>> If I manage to find a fix today I'll send it, otherwise this can wait
>>>> until next year.
>>>
>>> Something like this?
>>>
>>> diff --git a/xen/Makefile b/xen/Makefile
>>> index dc6862e04d..2d7a567c9c 100644
>>> --- a/xen/Makefile
>>> +++ b/xen/Makefile
>>> @@ -253,14 +253,14 @@ kconfig := silentoldconfig oldconfig config
>>> menuconfig defconfig \
>>> randconfig
>>>  .PHONY: $(kconfig)
>>>  $(kconfig):
>>> -   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig
>>> ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" $@
>>> +   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig
>>> ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)"
>>> HOST_EXTRACFLAGS="$(APPEND_CFLAGS)" $@
>>>
>>>  include/config/%.conf: include/config/auto.conf.cmd $(KCONFIG_CONFIG)
>>> -   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig
>>> ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)"
>>> silentoldconfig
>>> +   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig
>>> ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)"
>>> HOST_EXTRACFLAGS="$(APPEND_CFLAGS)" silentoldconfig
>>>
>>>  # Allow people to just run `make` as before and not force them to
>>> configure
>>>  $(KCONFIG_CONFIG):
>>> -   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig
>>> ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)"
>>> defconfig
>>> +   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig
>>> ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)"
>>> HOST_EXTRACFLAGS="$(APPEND_CFLAGS)" defconfig
>>>
>>>  # Break the dependency chain for the first run
>>>  include/config/auto.conf.cmd: ;
>>>
>>
>> That should do the trick.
>>
>> Reviewed-by: Doug Goldstein <car...@cardoe.com>
>
> I got this to work as well:
>
> diff --git a/xen/tools/kconfig/Makefile b/xen/tools/kconfig/Makefile
> index aceaaed..32e2359 100644
> --- a/xen/tools/kconfig/Makefile
> +++ b/xen/tools/kconfig/Makefile
> @@ -155,7 +155,7 @@ check-lxdialog  :=
> $(srctree)/$(src)/lxdialog/check-lxdialog.sh
>  # Use recursively expanded variables so we do not call gcc unless
>  # we really need to do so. (Do not call gcc as part of make mrproper)
>  HOST_EXTRACFLAGS += $(shell $(CONFIG_SHELL) $(check-lxdialog) -ccflags) \
> --DLOCALE
> +-DLOCALE $(APPEND_CFLAGS)
>
>  # ===
>  # Shared Makefile for the various kconfig executables:
>
> But yours looks like it should work as well.
>
> Do you want to send a patch?

You can add this to it:

Reviewed-by: Alistair Francis <alistair.fran...@xilinx.com>
Tested-by: Alistair Francis <alistair.fran...@xilinx.com>

Thanks,

Alistair

>
> Thanks,
>
> Alistair
>
>>
>> --
>> Doug Goldstein
>>
>>
>> ___
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> https://lists.xen.org/xen-devel
>>

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking

2016-12-22 Thread Alistair Francis

On Thu, Dec 22, 2016 at 2:00 PM, Doug Goldstein <car...@cardoe.com> wrote:
> On 12/22/16 3:47 PM, Andrew Cooper wrote:
>> On 22/12/16 21:41, Alistair Francis wrote:
>>> On Thu, Dec 22, 2016 at 1:15 PM, Alistair Francis
>>> <alistair.fran...@xilinx.com> wrote:
>>>> On Thu, Dec 22, 2016 at 1:12 PM, Alistair Francis
>>>> <alistair.fran...@xilinx.com> wrote:
>>>>> On Thu, Dec 22, 2016 at 11:22 AM, Ian Jackson
>>>>> <ian.jack...@eu.citrix.com> wrote:
>>>>>> Alistair Francis writes ("Re: [Xen-devel] [PATCH v2 1/5] Remove
>>>>>> hardcoded strict -Werror checking"):
>>>>>>> On Thu, Dec 22, 2016 at 12:41 AM, Jan Beulich <jbeul...@suse.com>
>>>>>>> wrote:
>>>>>>>> On 20.12.16 at 20:46, <alistair.fran...@xilinx.com> wrote:
>>>>>>>>> Signed-off-by: Alistair Francis <alistair.fran...@xilinx.com>
>>>>>>>> Without some rationale given I don't think such changes are
>>>>>>>> acceptable at all. And then, as already pointed out others, the
>>>>>>>> use of -Werror is there not just for fun. If anything I think an
>>>>>>>> override to that default could be acceptable.
>>>>>>> Unfortunately the APPEND_CFLAGS=-Wno-error doesn't fix all the issues
>>>>>>> as I still see warnings/errors when building: tools/kconfig/conf.c.
>>>>>> That sounds like a bug to me.  Do you know why it's not effective
>>>>>> there ?
>>>>> It actually might be an issue in the way buildroot is handling the
>>>>> arguments.
>>>>>
>>>>> I'll look into it and see what I find after the holidays.
>>> I dug into this a little more. Adding the APPEND_CFLAGS="-Wno-error"
>>> fixes almost everything. The only problem I see is in the log below,
>>> where tools/kconfig/conf.c fails to build as the -Wno-error doesn't
>>> propagate down.
>>>
>>> If I manage to find a fix today I'll send it, otherwise this can wait
>>> until next year.
>>
>> Something like this?
>>
>> diff --git a/xen/Makefile b/xen/Makefile
>> index dc6862e04d..2d7a567c9c 100644
>> --- a/xen/Makefile
>> +++ b/xen/Makefile
>> @@ -253,14 +253,14 @@ kconfig := silentoldconfig oldconfig config
>> menuconfig defconfig \
>> randconfig
>>  .PHONY: $(kconfig)
>>  $(kconfig):
>> -   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig
>> ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)" $@
>> +   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig
>> ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)"
>> HOST_EXTRACFLAGS="$(APPEND_CFLAGS)" $@
>>
>>  include/config/%.conf: include/config/auto.conf.cmd $(KCONFIG_CONFIG)
>> -   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig
>> ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)"
>> silentoldconfig
>> +   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig
>> ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)"
>> HOST_EXTRACFLAGS="$(APPEND_CFLAGS)" silentoldconfig
>>
>>  # Allow people to just run `make` as before and not force them to
>> configure
>>  $(KCONFIG_CONFIG):
>> -   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig
>> ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)"
>> defconfig
>> +   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig
>> ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC="$(HOSTCC)" HOSTCXX="$(HOSTCXX)"
>> HOST_EXTRACFLAGS="$(APPEND_CFLAGS)" defconfig
>>
>>  # Break the dependency chain for the first run
>>  include/config/auto.conf.cmd: ;
>>
>
> That should do the trick.
>
> Reviewed-by: Doug Goldstein <car...@cardoe.com>

I got this to work as well:

diff --git a/xen/tools/kconfig/Makefile b/xen/tools/kconfig/Makefile
index aceaaed..32e2359 100644
--- a/xen/tools/kconfig/Makefile
+++ b/xen/tools/kconfig/Makefile
@@ -155,7 +155,7 @@ check-lxdialog  :=
$(srctree)/$(src)/lxdialog/check-lxdialog.sh
 # Use recursively expanded variables so we do not call gcc unless
 # we really need to do so. (Do not call gcc as part of make mrproper)
 HOST_EXTRACFLAGS += $(shell $(CONFIG_SHELL) $(check-lxdialog) -ccflags) \
--DLOCALE
+-DLOCALE $(APPEND_CFLAGS)

 # ===
 # Shared Makefile for the various kconfig executables:

But yours looks like it should work as well.

Do you want to send a patch?

Thanks,

Alistair

>
> --
> Doug Goldstein
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
>

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking

2016-12-22 Thread Alistair Francis

On Thu, Dec 22, 2016 at 1:15 PM, Alistair Francis
<alistair.fran...@xilinx.com> wrote:
> On Thu, Dec 22, 2016 at 1:12 PM, Alistair Francis
> <alistair.fran...@xilinx.com> wrote:
>> On Thu, Dec 22, 2016 at 11:22 AM, Ian Jackson <ian.jack...@eu.citrix.com> 
>> wrote:
>>> Alistair Francis writes ("Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded 
>>> strict -Werror checking"):
>>>> On Thu, Dec 22, 2016 at 12:41 AM, Jan Beulich <jbeul...@suse.com> wrote:
>>>>> On 20.12.16 at 20:46, <alistair.fran...@xilinx.com> wrote:
>>>> >> Signed-off-by: Alistair Francis <alistair.fran...@xilinx.com>
>>>> >
>>>> > Without some rationale given I don't think such changes are
>>>> > acceptable at all. And then, as already pointed out others, the
>>>> > use of -Werror is there not just for fun. If anything I think an
>>>> > override to that default could be acceptable.
>>>>
>>>> Unfortunately the APPEND_CFLAGS=-Wno-error doesn't fix all the issues
>>>> as I still see warnings/errors when building: tools/kconfig/conf.c.
>>>
>>> That sounds like a bug to me.  Do you know why it's not effective
>>> there ?
>>
>> It actually might be an issue in the way buildroot is handling the arguments.
>>
>> I'll look into it and see what I find after the holidays.

I dug into this a little more. Adding the APPEND_CFLAGS="-Wno-error"
fixes almost everything. The only problem I see is in the log below,
where tools/kconfig/conf.c fails to build as the -Wno-error doesn't
propagate down.

If I manage to find a fix today I'll send it, otherwise this can wait
until next year.

Thanks,

Alistair

>
> Nope, it does look like a Xen build issue. I included the full failing
> log below:
>
> PATH="/work/alistai/software/buildroot/output/host/bin:/work/alistai/software/buildroot/output/host/sbin:/work/alistai/software/buildroot/output/host/usr/bin:/work/alistai/software/buildroot/output/host/usr/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin"
> XEN_TARGET_ARCH=arm32
> CROSS_COMPILE=/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-
> PATH="/work/alistai/software/buildroot/output/host/bin:/work/alistai/software/buildroot/output/host/sbin:/work/alistai/software/buildroot/output/host/usr/bin:/work/alistai/software/buildroot/output/host/usr/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin"
> AR="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-ar"
> AS="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-as"
> LD="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-ld"
> NM="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-nm"
> CC="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-gcc"
> GCC="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-gcc"
> CPP="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-cpp"
> CXX="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-g++"
> FC="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-gfortran"
> F77="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-gfortran"
> RANLIB="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-ranlib"
> READELF="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-readelf"
> STRIP="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-strip"
> OBJCOPY="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-objcopy"
> OBJDUMP="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-objdump"
> AR_FOR_BUILD="/usr/bin/ar" AS_FOR_BUILD="/usr/bin/as"
> CC_FOR_BUILD="/usr/bin/gcc" GCC_FOR_BUILD="/usr/bin/gcc"
> CXX_FOR_BUILD="/usr/bin/g++" LD_FOR_BUILD="/usr/bin/ld"
> CPPFLAGS_FOR_BUILD="-I/work/alistai/software/buildroot/output/host/usr/include"
> CFLAGS_FOR_BUILD="-O2
> -I/work/alistai/software/buildroot/output/host/usr/include"
> CXXFLAGS_FOR_BUILD="-O2
> -I/work/alistai/software/buildroot/output/host/usr/include"
> LDFLAGS_FOR_BUILD="-L/work/alistai/software/buildroot/output/host/lib
> -L/work/alistai/software/buildroot/output/host/usr/lib
> -Wl,-rpath,/work/alistai/software/buildroot/output/host/usr/lib"
> FCFLAGS_FOR_BUILD=""
> DEFAULT_ASSEMBLER="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-as"
>

Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking

2016-12-22 Thread Alistair Francis

On Thu, Dec 22, 2016 at 1:12 PM, Alistair Francis
<alistair.fran...@xilinx.com> wrote:
> On Thu, Dec 22, 2016 at 11:22 AM, Ian Jackson <ian.jack...@eu.citrix.com> 
> wrote:
>> Alistair Francis writes ("Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded 
>> strict -Werror checking"):
>>> On Thu, Dec 22, 2016 at 12:41 AM, Jan Beulich <jbeul...@suse.com> wrote:
>>>> On 20.12.16 at 20:46, <alistair.fran...@xilinx.com> wrote:
>>> >> Signed-off-by: Alistair Francis <alistair.fran...@xilinx.com>
>>> >
>>> > Without some rationale given I don't think such changes are
>>> > acceptable at all. And then, as already pointed out others, the
>>> > use of -Werror is there not just for fun. If anything I think an
>>> > override to that default could be acceptable.
>>>
>>> Unfortunately the APPEND_CFLAGS=-Wno-error doesn't fix all the issues
>>> as I still see warnings/errors when building: tools/kconfig/conf.c.
>>
>> That sounds like a bug to me.  Do you know why it's not effective
>> there ?
>
> It actually might be an issue in the way buildroot is handling the arguments.
>
> I'll look into it and see what I find after the holidays.

Nope, it does look like a Xen build issue. I included the full failing
log below:

PATH="/work/alistai/software/buildroot/output/host/bin:/work/alistai/software/buildroot/output/host/sbin:/work/alistai/software/buildroot/output/host/usr/bin:/work/alistai/software/buildroot/output/host/usr/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin"
XEN_TARGET_ARCH=arm32
CROSS_COMPILE=/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-
PATH="/work/alistai/software/buildroot/output/host/bin:/work/alistai/software/buildroot/output/host/sbin:/work/alistai/software/buildroot/output/host/usr/bin:/work/alistai/software/buildroot/output/host/usr/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin"
AR="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-ar"
AS="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-as"
LD="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-ld"
NM="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-nm"
CC="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-gcc"
GCC="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-gcc"
CPP="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-cpp"
CXX="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-g++"
FC="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-gfortran"
F77="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-gfortran"
RANLIB="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-ranlib"
READELF="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-readelf"
STRIP="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-strip"
OBJCOPY="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-objcopy"
OBJDUMP="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-objdump"
AR_FOR_BUILD="/usr/bin/ar" AS_FOR_BUILD="/usr/bin/as"
CC_FOR_BUILD="/usr/bin/gcc" GCC_FOR_BUILD="/usr/bin/gcc"
CXX_FOR_BUILD="/usr/bin/g++" LD_FOR_BUILD="/usr/bin/ld"
CPPFLAGS_FOR_BUILD="-I/work/alistai/software/buildroot/output/host/usr/include"
CFLAGS_FOR_BUILD="-O2
-I/work/alistai/software/buildroot/output/host/usr/include"
CXXFLAGS_FOR_BUILD="-O2
-I/work/alistai/software/buildroot/output/host/usr/include"
LDFLAGS_FOR_BUILD="-L/work/alistai/software/buildroot/output/host/lib
-L/work/alistai/software/buildroot/output/host/usr/lib
-Wl,-rpath,/work/alistai/software/buildroot/output/host/usr/lib"
FCFLAGS_FOR_BUILD=""
DEFAULT_ASSEMBLER="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-as"
DEFAULT_LINKER="/work/alistai/software/buildroot/output/host/usr/bin/arm-linux-ld"
CPPFLAGS="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64" APPEND_CFLAGS="-Wno-error -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -Os "
CXXFLAGS="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64  -Os " LDFLAGS="" FAPPEND_CFLAGS="-Wno-error
-Os " FFLAGS=" -Os "
PKG_CONFIG="/work/alistai/software/buildroot/output/host/usr/bin/pkg-config"
STAGING_DIR="/work/alistai/software/buildroot/output/host/usr/arm-buildroot-linux-musleabihf/sysroot"
INTLTOOL_PERL=/usr/bin/perl /usr/bin/make -j11 di

Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking

2016-12-22 Thread Alistair Francis

On Thu, Dec 22, 2016 at 11:22 AM, Ian Jackson <ian.jack...@eu.citrix.com> wrote:
> Alistair Francis writes ("Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded 
> strict -Werror checking"):
>> On Thu, Dec 22, 2016 at 12:41 AM, Jan Beulich <jbeul...@suse.com> wrote:
>>> On 20.12.16 at 20:46, <alistair.fran...@xilinx.com> wrote:
>> >> Signed-off-by: Alistair Francis <alistair.fran...@xilinx.com>
>> >
>> > Without some rationale given I don't think such changes are
>> > acceptable at all. And then, as already pointed out others, the
>> > use of -Werror is there not just for fun. If anything I think an
>> > override to that default could be acceptable.
>>
>> Unfortunately the APPEND_CFLAGS=-Wno-error doesn't fix all the issues
>> as I still see warnings/errors when building: tools/kconfig/conf.c.
>
> That sounds like a bug to me.  Do you know why it's not effective
> there ?

It actually might be an issue in the way buildroot is handling the arguments.

I'll look into it and see what I find after the holidays.

Thanks,

Alistair

>
>> Everyone seems fairly open to an override. Is a environment variable,
>> which if set will disable Werror acceptable? Something like NO_ERROR=Y
>> which will result in no -Werror being appended.
>
> Yes, an environment variable would be acceptable, but it should have
> the right name and semantics and ideally we could reuse an existing
> variable or fix it if it is broken.
>
> How about `APPEND_CFLAGS=-Wno-error' ? :-)
>
> Thanks,
> Ian.
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking

2016-12-22 Thread Alistair Francis

On Thu, Dec 22, 2016 at 12:41 AM, Jan Beulich <jbeul...@suse.com> wrote:
>>>> On 20.12.16 at 20:46, <alistair.fran...@xilinx.com> wrote:
>> Signed-off-by: Alistair Francis <alistair.fran...@xilinx.com>
>
> Without some rationale given I don't think such changes are
> acceptable at all. And then, as already pointed out others, the
> use of -Werror is there not just for fun. If anything I think an
> override to that default could be acceptable.

Unfortunately the APPEND_CFLAGS=-Wno-error doesn't fix all the issues
as I still see warnings/errors when building: tools/kconfig/conf.c.

I understand that you want it in by default.

Everyone seems fairly open to an override. Is a environment variable,
which if set will disable Werror acceptable? Something like NO_ERROR=Y
which will result in no -Werror being appended.

Thanks,

Alistair

>
> Jan
>

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 5/5] tools/blktap2/drivers: Remove non-existent sys/sysctl.h include

2016-12-22 Thread Alistair Francis

On Thu, Dec 22, 2016 at 2:54 AM, Wei Liu <wei.l...@citrix.com> wrote:
> On Tue, Dec 20, 2016 at 11:47:00AM -0800, Alistair Francis wrote:
>> To avoid build errors related to missing file 'sys/sysctl.h' by removing
>> the #include statement.
>>
>> Signed-off-by: Alistair Francis <alistair.fran...@xilinx.com>
>
> I can find this in Linux. Maybe this is also due to the libc you're
> using?

Yes, I think you are right. I am using musl when I see the error.

>
> On the flip side, if this header is unused anyway I think I'm fine with
> taking this patch.

Thanks, that is what I was thinking too.

Thanks,

Alistair

>
>> ---
>>  tools/blktap2/drivers/block-remus.c | 1 -
>>  1 file changed, 1 deletion(-)
>>
>> diff --git a/tools/blktap2/drivers/block-remus.c 
>> b/tools/blktap2/drivers/block-remus.c
>> index 079588d..7401800 100644
>> --- a/tools/blktap2/drivers/block-remus.c
>> +++ b/tools/blktap2/drivers/block-remus.c
>> @@ -54,7 +54,6 @@
>>  #include 
>>  #include 
>>  #include 
>> -#include 
>>  #include 
>>  #include 
>>
>> --
>> 2.7.4
>>

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking

2016-12-20 Thread Alistair Francis

On Tue, Dec 20, 2016 at 12:16 PM, Andrew Cooper
<andrew.coop...@citrix.com> wrote:
> On 20/12/2016 20:06, Doug Goldstein wrote:
>> On 12/20/16 1:46 PM, Alistair Francis wrote:
>>> Signed-off-by: Alistair Francis <alistair.fran...@xilinx.com>
>>> ---
>>>  Config.mk  | 2 +-
>>>  tools/blktap2/drivers/Makefile | 1 -
>>>  tools/libxl/Makefile   | 2 +-
>>>  tools/xentrace/Makefile| 2 --
>>>  4 files changed, 2 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/Config.mk b/Config.mk
>>> index 3ec7367..e3cda81 100644
>>> --- a/Config.mk
>>> +++ b/Config.mk
>>> @@ -34,7 +34,7 @@ CONFIG_$(XEN_OS) := y
>>>  SHELL ?= /bin/sh
>>>
>>>  # Tools to run on system hosting the build
>>> -HOSTCFLAGS  = -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer
>>> +HOSTCFLAGS  = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer
>>>  HOSTCFLAGS += -fno-strict-aliasing
>>>
>>>  DISTDIR ?= $(XEN_ROOT)/dist
>>> diff --git a/tools/blktap2/drivers/Makefile b/tools/blktap2/drivers/Makefile
>>> index 5328c40..7a62a3f 100644
>>> --- a/tools/blktap2/drivers/Makefile
>>> +++ b/tools/blktap2/drivers/Makefile
>>> @@ -9,7 +9,6 @@ QCOW_UTIL  = img2qcow qcow-create qcow2raw
>>>  LOCK_UTIL  = lock-util
>>>  INST_DIR   = $(sbindir)
>>>
>>> -CFLAGS+= -Werror
>>>  CFLAGS+= -Wno-unused
>>>  CFLAGS+= -fno-strict-aliasing
>>>  CFLAGS+= -I$(BLKTAP_ROOT)/include -I$(BLKTAP_ROOT)/drivers
>>> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
>>> index 91e2f97..e8a37ef 100644
>>> --- a/tools/libxl/Makefile
>>> +++ b/tools/libxl/Makefile
>>> @@ -11,7 +11,7 @@ MINOR = 0
>>>  XLUMAJOR = 4.9
>>>  XLUMINOR = 0
>>>
>>> -CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \
>>> +CFLAGS += -Wno-format-zero-length -Wmissing-declarations \
>>>  -Wno-declaration-after-statement -Wformat-nonliteral
>>>  CFLAGS += -I. -fPIC
>>>
>>> diff --git a/tools/xentrace/Makefile b/tools/xentrace/Makefile
>>> index c8c36a8..ac5c534 100644
>>> --- a/tools/xentrace/Makefile
>>> +++ b/tools/xentrace/Makefile
>>> @@ -1,8 +1,6 @@
>>>  XEN_ROOT=$(CURDIR)/../..
>>>  include $(XEN_ROOT)/tools/Rules.mk
>>>
>>> -CFLAGS += -Werror
>>> -
>>>  CFLAGS += $(CFLAGS_libxenevtchn)
>>>  CFLAGS += $(CFLAGS_libxenctrl)
>>>  LDLIBS += $(LDLIBS_libxenevtchn)
>>>
>> Can you pass -Wno-error in EXTRA_CFLAGS from 2/5? Wish I could take
>> credit for the idea but it was all Andrew Cooper's.

I tried that, I still see errors when building lower levels like tools/xentrace.

>
> The point is that, especially with kernel-level development, almost all
> warnings are relevant to correctness.  I have only seen 2? false
> positives in 5 years, and have lost count of how many issues -Werror has
> caught before the code actually got committed.

I agree, but the problem is that as warnings change these cause all
sorts of build issues.

Thanks,

Alistair

>
> ~Andrew
>

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 0/5] General Build Fixes

2016-12-20 Thread Alistair Francis

On Tue, Dec 20, 2016 at 11:53 AM, Konrad Rzeszutek Wilk
<konrad.w...@oracle.com> wrote:
> On Tue, Dec 20, 2016 at 11:46:55AM -0800, Alistair Francis wrote:
>> This patch series is a list of build issues that appeared when
>> buildling Xen 4.8.0 in buildroot. Hopefully some of them can be
>
> Is there an corresponding patch in buildroot for using Xen?

Not yet. Buildroot currently builds Xen 4.7.1. I sent a patch a day or
two ago to update it to version 4.8.0 with my original patch series
included.

I will have to repost to buildroot with these new patches included.

>
> Thank you for reposting!

No worries! Thanks for reviewing.

Alistair

>
>> accepted upstream to help others who are trying to build Xen in
>> the future.
>>
>> V2:
>>  - Remove the #include path changes
>> - It turns out this only applies to musl (although it shouldn't
>>   break glibc though). Instead of renaming the #include files I
>>   have just removed the -Werror flags.
>>  - Allow people building Xen to pass in EXTRA_CFLAGS.
>>
>> Alistair Francis (5):
>>   Remove hardcoded strict -Werror checking
>>   config/StdGNU.mk: Allows users to pass in EXTRA_CFLAGS
>>   tools/blktap2/vhd: Remove unused struct stat stats
>>   tools/blktap2: Fix missing header file
>>   tools/blktap2/drivers: Remove non-existent sys/sysctl.h include
>>
>>  Config.mk  | 2 +-
>>  config/StdGNU.mk   | 3 +++
>>  tools/blktap2/drivers/Makefile | 1 -
>>  tools/blktap2/drivers/block-remus.c| 1 -
>>  tools/blktap2/include/atomicio.h   | 2 ++
>>  tools/blktap2/vhd/lib/libvhd-journal.c | 1 -
>>  tools/libxl/Makefile   | 2 +-
>>  tools/xentrace/Makefile| 2 --
>>  8 files changed, 7 insertions(+), 7 deletions(-)
>>
>> --
>> 2.7.4
>>

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2 0/5] General Build Fixes

2016-12-20 Thread Alistair Francis

This patch series is a list of build issues that appeared when
buildling Xen 4.8.0 in buildroot. Hopefully some of them can be
accepted upstream to help others who are trying to build Xen in
the future.

V2:
 - Remove the #include path changes
- It turns out this only applies to musl (although it shouldn't
  break glibc though). Instead of renaming the #include files I
  have just removed the -Werror flags.
 - Allow people building Xen to pass in EXTRA_CFLAGS.

Alistair Francis (5):
  Remove hardcoded strict -Werror checking
  config/StdGNU.mk: Allows users to pass in EXTRA_CFLAGS
  tools/blktap2/vhd: Remove unused struct stat stats
  tools/blktap2: Fix missing header file
  tools/blktap2/drivers: Remove non-existent sys/sysctl.h include

 Config.mk  | 2 +-
 config/StdGNU.mk   | 3 +++
 tools/blktap2/drivers/Makefile | 1 -
 tools/blktap2/drivers/block-remus.c| 1 -
 tools/blktap2/include/atomicio.h   | 2 ++
 tools/blktap2/vhd/lib/libvhd-journal.c | 1 -
 tools/libxl/Makefile   | 2 +-
 tools/xentrace/Makefile| 2 --
 8 files changed, 7 insertions(+), 7 deletions(-)

-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2 2/5] config/StdGNU.mk: Allows users to pass in EXTRA_CFLAGS

2016-12-20 Thread Alistair Francis

Signed-off-by: Alistair Francis <alistair.fran...@xilinx.com>
---
 config/StdGNU.mk | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/config/StdGNU.mk b/config/StdGNU.mk
index 6be8233..a6cdd82 100644
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@ -35,6 +35,9 @@ UTIL_LIBS = -lutil
 SONAME_LDFLAG = -soname
 SHLIB_LDFLAGS = -shared
 
+# Allow users to add extra CFLAGS
+CFLAGS += $(EXTRA_CFLAGS)
+
 ifeq ($(lto),y)
 CFLAGS += -flto
 LDFLAGS-$(clang) += -plugin LLVMgold.so
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2 5/5] tools/blktap2/drivers: Remove non-existent sys/sysctl.h include

2016-12-20 Thread Alistair Francis

To avoid build errors related to missing file 'sys/sysctl.h' by removing
the #include statement.

Signed-off-by: Alistair Francis <alistair.fran...@xilinx.com>
---
 tools/blktap2/drivers/block-remus.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/blktap2/drivers/block-remus.c 
b/tools/blktap2/drivers/block-remus.c
index 079588d..7401800 100644
--- a/tools/blktap2/drivers/block-remus.c
+++ b/tools/blktap2/drivers/block-remus.c
@@ -54,7 +54,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2 3/5] tools/blktap2/vhd: Remove unused struct stat stats

2016-12-20 Thread Alistair Francis

The unsued variable 'struct stat stats' causes build errors in some
situations. As it isn't used just remove it.

Signed-off-by: Alistair Francis <alistair.fran...@xilinx.com>
---
 tools/blktap2/vhd/lib/libvhd-journal.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/blktap2/vhd/lib/libvhd-journal.c 
b/tools/blktap2/vhd/lib/libvhd-journal.c
index 26e26e7..862890f 100644
--- a/tools/blktap2/vhd/lib/libvhd-journal.c
+++ b/tools/blktap2/vhd/lib/libvhd-journal.c
@@ -1260,7 +1260,6 @@ vhd_journal_create(vhd_journal_t *j, const char *file, 
const char *jfile)
int i, err;
size_t size;
off_t off;
-   struct stat stats;
 
memset(j, 0, sizeof(vhd_journal_t));
j->jfd = -1;
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2 4/5] tools/blktap2: Fix missing header file

2016-12-20 Thread Alistair Francis

To avoid build errors relating to missing delcarations of ssize_t add
the appripriote header file to atomic.h.

Signed-off-by: Alistair Francis <alistair.fran...@xilinx.com>
---
 tools/blktap2/include/atomicio.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/blktap2/include/atomicio.h b/tools/blktap2/include/atomicio.h
index 7eccf20..5a1120e 100644
--- a/tools/blktap2/include/atomicio.h
+++ b/tools/blktap2/include/atomicio.h
@@ -25,6 +25,8 @@
  * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */
 
+#include 
+
 /*
  * Ensure all of data on socket comes through. f==read || f==vwrite
  */
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking

2016-12-20 Thread Alistair Francis

Signed-off-by: Alistair Francis <alistair.fran...@xilinx.com>
---
 Config.mk  | 2 +-
 tools/blktap2/drivers/Makefile | 1 -
 tools/libxl/Makefile   | 2 +-
 tools/xentrace/Makefile| 2 --
 4 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/Config.mk b/Config.mk
index 3ec7367..e3cda81 100644
--- a/Config.mk
+++ b/Config.mk
@@ -34,7 +34,7 @@ CONFIG_$(XEN_OS) := y
 SHELL ?= /bin/sh
 
 # Tools to run on system hosting the build
-HOSTCFLAGS  = -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer
+HOSTCFLAGS  = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer
 HOSTCFLAGS += -fno-strict-aliasing
 
 DISTDIR ?= $(XEN_ROOT)/dist
diff --git a/tools/blktap2/drivers/Makefile b/tools/blktap2/drivers/Makefile
index 5328c40..7a62a3f 100644
--- a/tools/blktap2/drivers/Makefile
+++ b/tools/blktap2/drivers/Makefile
@@ -9,7 +9,6 @@ QCOW_UTIL  = img2qcow qcow-create qcow2raw
 LOCK_UTIL  = lock-util
 INST_DIR   = $(sbindir)
 
-CFLAGS+= -Werror
 CFLAGS+= -Wno-unused
 CFLAGS+= -fno-strict-aliasing
 CFLAGS+= -I$(BLKTAP_ROOT)/include -I$(BLKTAP_ROOT)/drivers
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 91e2f97..e8a37ef 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -11,7 +11,7 @@ MINOR = 0
 XLUMAJOR = 4.9
 XLUMINOR = 0
 
-CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \
+CFLAGS += -Wno-format-zero-length -Wmissing-declarations \
-Wno-declaration-after-statement -Wformat-nonliteral
 CFLAGS += -I. -fPIC
 
diff --git a/tools/xentrace/Makefile b/tools/xentrace/Makefile
index c8c36a8..ac5c534 100644
--- a/tools/xentrace/Makefile
+++ b/tools/xentrace/Makefile
@@ -1,8 +1,6 @@
 XEN_ROOT=$(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-CFLAGS += -Werror
-
 CFLAGS += $(CFLAGS_libxenevtchn)
 CFLAGS += $(CFLAGS_libxenctrl)
 LDLIBS += $(LDLIBS_libxenevtchn)
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/7] Remove hardcoded strict -Werror checking

2016-12-20 Thread Alistair Francis

On Mon, Dec 19, 2016 at 7:53 PM, Doug Goldstein <car...@cardoe.com> wrote:
> On 12/17/16 9:51 AM, Konrad Rzeszutek Wilk wrote:
>> On Fri, Dec 16, 2016 at 02:56:01PM -0800, Alistair Francis wrote:
>>> Signed-off-by: Alistair Francis <alistair.fran...@xilinx.com>
>>
>>
>> Why?
>
> *adjusts his distro maintainer hat* It's considered really bad form for
> upstreams to push -Werror in their projects. However I know there's
> upstream interest to keep it. The compromise would probably be to get my
> rear in gear and get a wider range of distros testing with Travis CI /
> GitLab CI.

I agree with both points. I understand why upstream wants it there,
but it's a pain.

What about an option to override and remove Werror, so it can still be
enabled by default?

Thanks,

Alistair

>
> --
> Doug Goldstein
>

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/7] Remove hardcoded strict -Werror checking

2016-12-20 Thread Alistair Francis

On Tue, Dec 20, 2016 at 9:21 AM, Konrad Rzeszutek Wilk
<konrad.w...@oracle.com> wrote:
> On Tue, Dec 20, 2016 at 11:02:15AM -0600, Doug Goldstein wrote:
>> On 12/20/16 10:05 AM, Konrad Rzeszutek Wilk wrote:
>> > On Mon, Dec 19, 2016 at 09:53:02PM -0600, Doug Goldstein wrote:
>> >> On 12/17/16 9:51 AM, Konrad Rzeszutek Wilk wrote:
>> >>> On Fri, Dec 16, 2016 at 02:56:01PM -0800, Alistair Francis wrote:
>> >>>> Signed-off-by: Alistair Francis <alistair.fran...@xilinx.com>
>> >>>
>> >>>
>> >>> Why?
>> >>
>> >> *adjusts his distro maintainer hat* It's considered really bad form for
>> >> upstreams to push -Werror in their projects. However I know there's
>> >> upstream interest to keep it. The compromise would probably be to get my
>> >> rear in gear and get a wider range of distros testing with Travis CI /
>> >> GitLab CI.
>> >
>> > So.. why not do something like this:
>> >
>> >
>> > diff --git a/config/StdGNU.mk b/config/StdGNU.mk
>> > index 6be8233..fd2d5b9 100644
>> > --- a/config/StdGNU.mk
>> > +++ b/config/StdGNU.mk
>> > @@ -39,3 +39,5 @@ ifeq ($(lto),y)
>> >  CFLAGS += -flto
>> >  LDFLAGS-$(clang) += -plugin LLVMgold.so
>> >  endif
>> > +
>> > +CFLAGS += $(EXTRA_CFLAGS)
>> >
>> > And have the BuildRoot script do something like:
>> >
>> >
>> > EXTRA_CFLAGS=$(CFLAGS)
>> > unset CFLAGS
>> >
>> > make -C xen
>> >
>> > ?
>> >
>>
>> This was really to replace patch 3/7 right? Cause I think this would be
>> an ok change. It'd certainly help me with Yocto where I have to pass in
>> CFLAGS (need to pass in the sysroot of the target compiler).
>
> Yes sorry.

Yeah, this could work as well (for patch 3).

Should I re-spin with something like that?

Thanks,

Alistair

>>
>> --
>> Doug Goldstein
>>
>
>
>

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 4/7] tools: Update sys/poll.h to poll.h

2016-12-20 Thread Alistair Francis

On Mon, Dec 19, 2016 at 8:00 PM, Doug Goldstein <car...@cardoe.com> wrote:
> On 12/19/16 12:01 PM, Alistair Francis wrote:
>> On Sat, Dec 17, 2016 at 7:55 AM, Konrad Rzeszutek Wilk
>> <konrad.w...@oracle.com> wrote:
>>> On Fri, Dec 16, 2016 at 02:56:04PM -0800, Alistair Francis wrote:
>>>> To avoid this build error with newer build systems:
>>>
>>> And what is newer? GCC 5? 6?
>>
>> In this case it is GCC 5.
>>
>
> No. Its a libc thing. I wonder what libc you're using because glibc 2.24
> still has it at sys/pool.h for me.

Yeah, you are right. I don't know what I was thinking.

I'm using musl version 1.1.15 which prints a warning every time you
call sys/poll.h.

Looking at the latest glibc master branch glibc supports both and
doesn't have any warnings. This probably isn't the right thing to do
then. I will just have to remove Werror instead.

Thanks,

Alistair

>
> --
> Doug Goldstein
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
>

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 5/7] tools/blktap2: Update sys/signal.h to signal.h

2016-12-19 Thread Alistair Francis

On Sat, Dec 17, 2016 at 7:56 AM, Konrad Rzeszutek Wilk
<konrad.w...@oracle.com> wrote:
> On Fri, Dec 16, 2016 at 02:56:05PM -0800, Alistair Francis wrote:
>> To avoid this build error with newer build systems:
>> error: #warning redirecting incorrect #include  to
>> [-Werror=cpp]
>
> And what is the 'newer build system' you speak off?

Sorry I should have specified more there.

It's GCC 5 that I am seeing the problem on.

Thanks,

Alistair

>
> Thanks!
>>
>> Rename sys/signal.h to signal.h
>>
>> Signed-off-by: Alistair Francis <alistair.fran...@xilinx.com>
>> ---
>>  tools/blktap2/drivers/tapdisk-server.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tools/blktap2/drivers/tapdisk-server.c 
>> b/tools/blktap2/drivers/tapdisk-server.c
>> index eecde3d..71315bb 100644
>> --- a/tools/blktap2/drivers/tapdisk-server.c
>> +++ b/tools/blktap2/drivers/tapdisk-server.c
>> @@ -30,7 +30,7 @@
>>  #include 
>>  #include 
>>  #include 
>> -#include 
>> +#include 
>>
>>  #include "tapdisk-utils.h"
>>  #include "tapdisk-server.h"
>> --
>> 2.7.4
>>
>>
>> ___
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> https://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 4/7] tools: Update sys/poll.h to poll.h

2016-12-19 Thread Alistair Francis

On Sat, Dec 17, 2016 at 7:55 AM, Konrad Rzeszutek Wilk
<konrad.w...@oracle.com> wrote:
> On Fri, Dec 16, 2016 at 02:56:04PM -0800, Alistair Francis wrote:
>> To avoid this build error with newer build systems:
>
> And what is newer? GCC 5? 6?

In this case it is GCC 5.

Thanks,

Alistair

>
> Thanks.
>>   error: #warning redirecting incorrect #include  to
>>   [-Werror=cpp]
>>
>> Rename sys/poll.h to poll.h
>>
>> Signed-off-by: Alistair Francis <alistair.fran...@xilinx.com>
>> ---
>>  tools/libxl/libxl_internal.h   | 2 +-
>>  tools/tests/xen-access/xen-access.c| 2 +-
>>  tools/xenstat/libxenstat/src/xenstat_qmp.c | 2 +-
>>  tools/xentrace/xentrace.c  | 2 +-
>>  4 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
>> index 5f46578..acf9ac2 100644
>> --- a/tools/libxl/libxl_internal.h
>> +++ b/tools/libxl/libxl_internal.h
>> @@ -38,7 +38,7 @@
>>  #include 
>>
>>  #include 
>> -#include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> diff --git a/tools/tests/xen-access/xen-access.c 
>> b/tools/tests/xen-access/xen-access.c
>> index 9d4f957..887bcd9 100644
>> --- a/tools/tests/xen-access/xen-access.c
>> +++ b/tools/tests/xen-access/xen-access.c
>> @@ -36,7 +36,7 @@
>>  #include 
>>  #include 
>>  #include 
>> -#include 
>> +#include 
>>
>>  #include 
>>  #include 
>> diff --git a/tools/xenstat/libxenstat/src/xenstat_qmp.c 
>> b/tools/xenstat/libxenstat/src/xenstat_qmp.c
>> index a87c937..3fda487 100644
>> --- a/tools/xenstat/libxenstat/src/xenstat_qmp.c
>> +++ b/tools/xenstat/libxenstat/src/xenstat_qmp.c
>> @@ -14,7 +14,7 @@
>>  #include 
>>  #include 
>>  #include 
>> -#include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> diff --git a/tools/xentrace/xentrace.c b/tools/xentrace/xentrace.c
>> index f09fe6c..364a6fd 100644
>> --- a/tools/xentrace/xentrace.c
>> +++ b/tools/xentrace/xentrace.c
>> @@ -24,7 +24,7 @@
>>  #include 
>>  #include 
>>  #include 
>> -#include 
>> +#include 
>>  #include 
>>
>>  #include 
>> --
>> 2.7.4
>>
>>
>> ___
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> https://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/7] Remove hardcoded strict -Werror checking

2016-12-19 Thread Alistair Francis

On Sat, Dec 17, 2016 at 7:51 AM, Konrad Rzeszutek Wilk
<konrad.w...@oracle.com> wrote:
> On Fri, Dec 16, 2016 at 02:56:01PM -0800, Alistair Francis wrote:
>> Signed-off-by: Alistair Francis <alistair.fran...@xilinx.com>
>
>
> Why?

Hey Konrad,

The problem that I have is that we build Xen releases in buildroot. As
things change (GCC version usually) new warnings are generated for
issues that previously never caused any problems. Instead of
constantly fixing these small warnings it is easier to disable Werror.

I understand that for development this isn't what you want. I just
thought it was worth at least sending this up.

Maybe a way to disable Werror when configuring would be the best solution?

Thanks,

Alistair

>
> Thanks!
>> ---
>>  Config.mk | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Config.mk b/Config.mk
>> index 3ec7367..e3cda81 100644
>> --- a/Config.mk
>> +++ b/Config.mk
>> @@ -34,7 +34,7 @@ CONFIG_$(XEN_OS) := y
>>  SHELL ?= /bin/sh
>>
>>  # Tools to run on system hosting the build
>> -HOSTCFLAGS  = -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer
>> +HOSTCFLAGS  = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer
>>  HOSTCFLAGS += -fno-strict-aliasing
>>
>>  DISTDIR ?= $(XEN_ROOT)/dist
>> --
>> 2.7.4
>>
>>
>> ___
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> https://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 4/7] tools: Update sys/poll.h to poll.h

2016-12-16 Thread Alistair Francis

To avoid this build error with newer build systems:
  error: #warning redirecting incorrect #include  to
  [-Werror=cpp]

Rename sys/poll.h to poll.h

Signed-off-by: Alistair Francis <alistair.fran...@xilinx.com>
---
 tools/libxl/libxl_internal.h   | 2 +-
 tools/tests/xen-access/xen-access.c| 2 +-
 tools/xenstat/libxenstat/src/xenstat_qmp.c | 2 +-
 tools/xentrace/xentrace.c  | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 5f46578..acf9ac2 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -38,7 +38,7 @@
 #include 
 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/tools/tests/xen-access/xen-access.c 
b/tools/tests/xen-access/xen-access.c
index 9d4f957..887bcd9 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -36,7 +36,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 #include 
diff --git a/tools/xenstat/libxenstat/src/xenstat_qmp.c 
b/tools/xenstat/libxenstat/src/xenstat_qmp.c
index a87c937..3fda487 100644
--- a/tools/xenstat/libxenstat/src/xenstat_qmp.c
+++ b/tools/xenstat/libxenstat/src/xenstat_qmp.c
@@ -14,7 +14,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/tools/xentrace/xentrace.c b/tools/xentrace/xentrace.c
index f09fe6c..364a6fd 100644
--- a/tools/xentrace/xentrace.c
+++ b/tools/xentrace/xentrace.c
@@ -24,7 +24,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #include 
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 7/7] tools/blktap2: Fix missing header file

2016-12-16 Thread Alistair Francis

To avoid build errors relating to missing delcarations of ssize_t add
the appripriote header file to atomic.h.

Signed-off-by: Alistair Francis <alistair.fran...@xilinx.com>
---
 tools/blktap2/include/atomicio.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/blktap2/include/atomicio.h b/tools/blktap2/include/atomicio.h
index 7eccf20..5a1120e 100644
--- a/tools/blktap2/include/atomicio.h
+++ b/tools/blktap2/include/atomicio.h
@@ -25,6 +25,8 @@
  * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */
 
+#include 
+
 /*
  * Ensure all of data on socket comes through. f==read || f==vwrite
  */
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 0/7] General Build Fixes

2016-12-16 Thread Alistair Francis

This patch series is a list of build issues that appeared when
buildling Xen 4.8.0 in buildroot. Hopefully some of them can be
accepted upstream to help others who are trying to build Xen in
the future.

Alistair Francis (6):
  Remove hardcoded strict -Werror checking
  tools/libxl: Remove hardcoded strict -Werror checking
  tools: Update sys/poll.h to poll.h
  tools/blktap2: Update sys/signal.h to signal.h
  tools/blktap2/vhd: Remove unused struct stat stats
  tools/blktap2: Fix missing header file

Yann E. MORIN (1):
  xen/Rules.mk: fix build with CFLAGS from environment

 Config.mk  | 2 +-
 tools/blktap2/drivers/tapdisk-server.c | 2 +-
 tools/blktap2/include/atomicio.h   | 2 ++
 tools/blktap2/vhd/lib/libvhd-journal.c | 1 -
 tools/libxl/Makefile   | 2 +-
 tools/libxl/libxl_internal.h   | 2 +-
 tools/tests/xen-access/xen-access.c| 2 +-
 tools/xenstat/libxenstat/src/xenstat_qmp.c | 2 +-
 tools/xentrace/xentrace.c  | 2 +-
 xen/Rules.mk   | 2 +-
 10 files changed, 10 insertions(+), 9 deletions(-)

-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 2/7] tools/libxl: Remove hardcoded strict -Werror checking

2016-12-16 Thread Alistair Francis

Signed-off-by: Alistair Francis <alistair.fran...@xilinx.com>
---
 tools/libxl/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 91e2f97..e8a37ef 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -11,7 +11,7 @@ MINOR = 0
 XLUMAJOR = 4.9
 XLUMINOR = 0
 
-CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \
+CFLAGS += -Wno-format-zero-length -Wmissing-declarations \
-Wno-declaration-after-statement -Wformat-nonliteral
 CFLAGS += -I. -fPIC
 
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 3/7] xen/Rules.mk: fix build with CFLAGS from environment

2016-12-16 Thread Alistair Francis

From: "Yann E. MORIN" 

When CFLAGS are passed from the environment, the first-level make
invocation will append -D__OBJECT_FILE__ to it, then call a second
make invocation, that will have those new CFLAGS in its environment,
but will also append -D__OBJECT_FILE__ to those.

Then, the compiler fails because __OBEJECT_FILE__ is defined twice.

Just undefine it before defining it again, as a *workaround* to this
issue.

Signed-off-by: "Yann E. MORIN" 
---
 xen/Rules.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 24d13dc..f8b8c2c 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -49,7 +49,7 @@ endif
 CFLAGS += -nostdinc -fno-builtin -fno-common
 CFLAGS += -Werror -Wredundant-decls -Wno-pointer-arith
 CFLAGS += -pipe -g -D__XEN__ -include $(BASEDIR)/include/xen/config.h
-CFLAGS += '-D__OBJECT_FILE__="$@"'
+CFLAGS += -U__OBJECT_FILE__ '-D__OBJECT_FILE__="$@"'
 
 ifneq ($(clang),y)
 # Clang doesn't understand this command line argument, and doesn't appear to
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 1/7] Remove hardcoded strict -Werror checking

2016-12-16 Thread Alistair Francis

Signed-off-by: Alistair Francis <alistair.fran...@xilinx.com>
---
 Config.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Config.mk b/Config.mk
index 3ec7367..e3cda81 100644
--- a/Config.mk
+++ b/Config.mk
@@ -34,7 +34,7 @@ CONFIG_$(XEN_OS) := y
 SHELL ?= /bin/sh
 
 # Tools to run on system hosting the build
-HOSTCFLAGS  = -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer
+HOSTCFLAGS  = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer
 HOSTCFLAGS += -fno-strict-aliasing
 
 DISTDIR ?= $(XEN_ROOT)/dist
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 5/7] tools/blktap2: Update sys/signal.h to signal.h

2016-12-16 Thread Alistair Francis

To avoid this build error with newer build systems:
error: #warning redirecting incorrect #include  to
[-Werror=cpp]

Rename sys/signal.h to signal.h

Signed-off-by: Alistair Francis <alistair.fran...@xilinx.com>
---
 tools/blktap2/drivers/tapdisk-server.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/blktap2/drivers/tapdisk-server.c 
b/tools/blktap2/drivers/tapdisk-server.c
index eecde3d..71315bb 100644
--- a/tools/blktap2/drivers/tapdisk-server.c
+++ b/tools/blktap2/drivers/tapdisk-server.c
@@ -30,7 +30,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "tapdisk-utils.h"
 #include "tapdisk-server.h"
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 6/7] tools/blktap2/vhd: Remove unused struct stat stats

2016-12-16 Thread Alistair Francis

The unsued variable 'struct stat stats' causes build errors in some
situations. As it isn't used just remove it.

Signed-off-by: Alistair Francis <alistair.fran...@xilinx.com>
---
 tools/blktap2/vhd/lib/libvhd-journal.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/blktap2/vhd/lib/libvhd-journal.c 
b/tools/blktap2/vhd/lib/libvhd-journal.c
index 26e26e7..862890f 100644
--- a/tools/blktap2/vhd/lib/libvhd-journal.c
+++ b/tools/blktap2/vhd/lib/libvhd-journal.c
@@ -1260,7 +1260,6 @@ vhd_journal_create(vhd_journal_t *j, const char *file, 
const char *jfile)
int i, err;
size_t size;
off_t off;
-   struct stat stats;
 
memset(j, 0, sizeof(vhd_journal_t));
j->jfd = -1;
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen ARM community call

2016-11-08 Thread Alistair Francis

On Tue, Nov 8, 2016 at 4:19 AM, Julien Grall  wrote:
> Hi all,
>
...
> I would suggest to start with a 1 hour meeting on the Wednesday 23rd
> November. I know that people are spread across different timezones, so I
> would like to gather thought before choosing a time.

I can't make it that week, but I would be interested in attending
future calls. I'm PST (UTC-8)

Thanks,

Alistair

>
> Your sincerely,
>
> --
> Julien Grall
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v1 1/1] xen/arm: Disable the Cortex-a53-edac

2016-10-07 Thread Alistair Francis

On Thu, Oct 6, 2016 at 9:36 AM, Edgar E. Iglesias
<edgar.igles...@gmail.com> wrote:
> From: "Edgar E. Iglesias" <edgar.igles...@xilinx.com>
>
> Disable the Cortex-a53-edac. Xen currently does not yet
> handle reads/writes to the implementation defined CPUMERRSR
> register.
>
> Signed-off-by: Edgar E. Iglesias <edgar.igles...@xilinx.com>

This solution looks fine to me and everything boots on ZynqMP as
expected with this patch.

Acked-by: Alistair Francis <alistair.fran...@xilinx.com>

Thanks,

Alistair


> ---
>  xen/arch/arm/domain_build.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index ce97359..e8a400c 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1188,6 +1188,7 @@ static int handle_node(struct domain *d, struct 
> kernel_info *kinfo,
>  DT_MATCH_COMPATIBLE("arm,psci-1.0"),
>  DT_MATCH_COMPATIBLE("arm,cortex-a7-pmu"),
>  DT_MATCH_COMPATIBLE("arm,cortex-a15-pmu"),
> +DT_MATCH_COMPATIBLE("arm,cortex-a53-edac"),
>  DT_MATCH_COMPATIBLE("arm,armv8-pmuv3"),
>  DT_MATCH_PATH("/cpus"),
>  DT_MATCH_TYPE("memory"),
> --
> 2.5.0
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

40 matches

Mail list logo