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

[Marc-André Lureau]

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)

>