Re: [Qemu-devel] [PATCH v3 1/4] QEMU_PACKED: Remove gcc_struct attribute in Windows non x86 targets

[Philippe Mathieu-Daudé]

On 5/3/19 5:56 PM, Marc-André Lureau wrote:
> Hi
> 
> Le ven. 3 mai 2019 à 17:23, Peter Maydell <address@hidden> a
> écrit :
> 
>> On Fri, 3 May 2019 at 06:07, Thomas Huth <address@hidden> wrote:
>>>
>>> On 03/05/2019 02.36, Cao Jiaxi wrote:
>>>> gcc_struct is for x86 only, and it generates an warning on ARM64
>> Clang/MinGW targets.
>>>>
>>>> Signed-off-by: Cao Jiaxi <address@hidden>
>>>> ---
>>>>  contrib/libvhost-user/libvhost-user.h | 2 +-
>>>>  include/qemu/compiler.h               | 2 +-
>>>>  scripts/cocci-macro-file.h            | 7 ++++++-
>>>>  slirp/src/util.h                      | 2 +-
>>>>  4 files changed, 9 insertions(+), 4 deletions(-)
>>
>>>> diff --git a/slirp/src/util.h b/slirp/src/util.h
>>>> index 01f1e0e068..278828fe3f 100644
>>>> --- a/slirp/src/util.h
>>>> +++ b/slirp/src/util.h
>>>> @@ -43,7 +43,7 @@
>>>>  #include <netinet/in.h>
>>>>  #endif
>>>>
>>>> -#if defined(_WIN32)
>>>> +#if defined(_WIN32) && (defined(__x86_64__) || defined(__i386__))
>>>>  # define SLIRP_PACKED __attribute__((gcc_struct, packed))
>>>>  #else
>>>>  # define SLIRP_PACKED __attribute__((packed))
>>>>
>>>
>>> The slirp code is currently on its way into a separate module, so you
>>> might need to provide that hunk to the libslirp folks again... I'm
>>> putting the slirp maintainers on CC:, maybe they can pick it up from
>> here.
>>
>> Yes, the slirp module has now landed in master, so this patch
>> definitely needs to be split into two. I've kept in my
>> target-arm.next tree the parts which are applicable to
>> the QEMU repo itself (ie everything except the slirp/ change),
>> so we just need a new patch for the slirp submodule part.
>>
>> Marc-André, Samuel -- what's the process for submitting and
>> getting reviewed changes to the slirp submodule now it's a
>> separate project ?
>>
> 
> It's hosted on gitlab.freedesktop.org, with some CI. It's fine to send
> patches on qemu devel, as long as Samuel or I are in CC. But in the long
> term, I think gitlab MR will be favoured (after a while using it, I think
> gitlab is better than ML for patches & bug tracking tbh)

Except when working offline (or with poor intermittent link).