qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH 1/2] util/osdep: Avoid madvise proto on modern Solaris


From: Daniel P . Berrangé
Subject: Re: [PATCH 1/2] util/osdep: Avoid madvise proto on modern Solaris
Date: Mon, 14 Mar 2022 19:01:06 +0000
User-agent: Mutt/2.1.5 (2021-12-30)

On Mon, Mar 14, 2022 at 01:18:00PM -0500, Andrew Deason wrote:
> On Mon, 14 Mar 2022 16:36:00 +0000
> Peter Maydell <peter.maydell@linaro.org> wrote:
> 
> > On Mon, 14 Mar 2022 at 16:12, Andrew Deason <adeason@sinenomine.net> wrote:
> > >  #ifdef CONFIG_SOLARIS
> > >  #include <sys/statvfs.h>
> > > +#ifndef HAVE_MADVISE_PROTO
> > >  /* See MySQL bug #7156 (http://bugs.mysql.com/bug.php?id=7156) for
> > >     discussion about Solaris header problems */
> > >  extern int madvise(char *, size_t, int);
> > >  #endif
> > > +#endif
> > 
> > Rather than keeping this inside a CONFIG_SOLARIS and only doing
> > the meson.build test if targetos == sunos, I would prefer it if we
> > unconditionally determined two things in meson.build:
> >  (1) do we have madvise in the usual way? (this is what we would
> >      want CONFIG_MADVISE to be, and might even be what it actually is)
> >  (2) do we have madvise but only if we provide a prototype for it
> >      ourselves? (maybe CONFIG_MADVISE_NO_PROTO)
> 
> CONFIG_MADVISE is set if we can cc.links() something that calls
> madvise(). If we're missing the prototype, that will fail with -Werror,
> but I expect succeeds otherwise. If cc.links() just uses the cflags for
> the build, then it seems like it might succeed or fail depending on
> --enable-werror. I see some other tests give -Werror as an explicit
> extra argument (HAVE_BROKEN_SIZE_MAX, and something for fuzzing); should
> this be doing the same to make sure it fails for a missing prototype?
> 
> Also just to mention, if we don't care about older Solaris, the
> prototype can just be unconditionally removed. It's pretty annoying to
> even try to build qemu from git on Solaris 11.4 and earlier, because
> many of the build requirements need to be installed/compiled manually
> (notably python 3.6+, but iirc also ninja, meson, etc). So I haven't
> really tried; there may be many other build issues there.

If we had a tiered support status, Solaris  would be tier 3
right now, as we have no testing of it at all. If it compiles
at any given point in time it is luck.

We have a general purpose platform support policy

  https://www.qemu.org/docs/master/about/build-platforms.html

where the common rule ends up being "the current major release,
and the previous major release for 2 years overlap".

The question is what counts as a major release from a Solaris
POV ? In terms of long life distros, our policy gives about
4-5 years of supportable life in the best case. I wouldn't
want to go beyond that ballpark for Solaris.  Can we come up
with an interpration of our policy to map to Solaris that
doesn't tie our hands for longer than 4-5 years worst case.


IOW, we certainly do NOT need to support arbitrarily old
Solaris. If madvise has done what we need for 4-5 years,
then we can likely not need to test for it, and just assume
its existance. This just requires someone to specify how
we interpret our build platform policy to exclude older
Solaris.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




reply via email to

[Prev in Thread] Current Thread [Next in Thread]