From: Peter Maydell <peter.maydell@linaro.org>
To: Andrew Deason <adeason@sinenomine.net>
Cc: Eduardo Habkost <eduardo@habkost.net>,
"Michael S. Tsirkin" <mst@redhat.com>,
Richard Henderson <richard.henderson@linaro.org>,
qemu-devel@nongnu.org, Igor Mammedov <imammedo@redhat.com>,
Ani Sinha <ani@anisinha.ca>, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH 1/2] util/osdep: Avoid madvise proto on modern Solaris
Date: Mon, 14 Mar 2022 16:36:00 +0000 [thread overview]
Message-ID: <CAFEAcA8DZby3k7rZ3F4m037b_qjANzEk-ekVQYxAm5tN1_v84w@mail.gmail.com> (raw)
In-Reply-To: <20220314154557.306-2-adeason@sinenomine.net>
On Mon, 14 Mar 2022 at 16:12, Andrew Deason <adeason@sinenomine.net> wrote:
>
> On older Solaris releases, we didn't get a protype for madvise, and so
> util/osdep.c provides its own prototype. Some time between the public
> Solaris 11.4 release and Solaris 11.4.42 CBE, we started getting an
> madvise prototype that looks like this:
>
> extern int madvise(void *, size_t, int);
>
> Which conflicts with the prototype in util/osdeps.c. Instead of always
> declaring this prototype, check if madvise() is already declared, so
> we don't need to declare it ourselves.
>
> Signed-off-by: Andrew Deason <adeason@sinenomine.net>
> ---
> I'm not sure if a test is needed for this at all; that is, how much qemu
> cares about earlier Solaris. The madvise prototype exists earlier in
> Solaris 11 (I'm not sure when it started appearing usefully), but in
> 11.4 and earlier it was compatible with the char* prototype.
> #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)
and then in osdep.h provide the prototype if CONFIG_MADVISE_NO_PROTO.
(osdep.h is where we provide "this is a fixup to the system headers"
portability workarounds, which this seems to be.)
This isn't the only .c file that directly calls madvise() :
softmmu/physmem.c does also. That looks like maybe a bug though:
perhaps it should be calling qemu_madvise()...
Side note: do you know why CONFIG_SOLARIS includes sys/statvfs.h ?
Is that unrelated to madvise() ?
thanks
-- PMM
next prev parent reply other threads:[~2022-03-14 16:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-14 15:45 [PATCH 0/2] Fixes for building on Solaris 11.4.42 CBE Andrew Deason
2022-03-14 15:45 ` [PATCH 1/2] util/osdep: Avoid madvise proto on modern Solaris Andrew Deason
2022-03-14 16:36 ` Peter Maydell [this message]
2022-03-14 18:18 ` Andrew Deason
2022-03-14 18:46 ` Peter Maydell
2022-03-14 19:01 ` Daniel P. Berrangé
2022-03-14 21:33 ` Andrew Deason
2022-03-14 15:45 ` [PATCH 2/2] hw/i386/acpi-build: Avoid 'sun' identifier Andrew Deason
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAFEAcA8DZby3k7rZ3F4m037b_qjANzEk-ekVQYxAm5tN1_v84w@mail.gmail.com \
--to=peter.maydell@linaro.org \
--cc=adeason@sinenomine.net \
--cc=ani@anisinha.ca \
--cc=eduardo@habkost.net \
--cc=imammedo@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).