Re: [Qemu-devel] [PATCH] configure: Make epoll_create1 test work around SPARC glibc bug

[Peter Maydell <peter.maydell@linaro.org>]

On 19 April 2011 20:59, Blue Swirl <blauwirbel@gmail.com> wrote:
> On Tue, Apr 19, 2011 at 10:48 PM, Peter Maydell
> <peter.maydell@linaro.org> wrote:
>> On 19 April 2011 20:37, Blue Swirl <blauwirbel@gmail.com> wrote:
>>> But then epoll would not be used.
>>
>> I think that's fine -- on a system which isn't advertising epoll
>> in its include files we shouldn't be trying to use it. It might
>> be buggy, or not the same function at all, for instance.
>>
>> Anybody who actually cares about epoll can upgrade their libc :-)
>
> Maybe epoll is not so interesting as madvise.

Indeed, it isn't; the only reason we check for it in configure is
so we know whether we can pass through the relevant syscalls for
linux-user mode. it's a pretty recent innovation so any guest app
using it should have a fallback path if it gets ENOSYS.
Incidentally, note that this configure check is for epoll_create1(),
not epoll_create(). [Some systems have only the former, so it has
a separate configure check.]

madvise() is used by qemu itself, so we care more there.

> But the check is not very specific, there could be some unrelated
> warning with the headers.

The check isn't supposed to be very specific; the idea is that it
does basically what the actual qemu source code does, ie just
use the function in a program that's compiled with -Werror. If there's
an unrelated problem with the header that produces a compile
warning then we also want that to cause the test to fail, because
that too will cause qemu compilation to fail later.

I think that the ideal for configure tests is that they test
for exactly the set of functionality used by the program itself;
that's what I'm trying to do here.

> How about checking in the compiled file for
> for example EPOLLIN, that should give a clear build failure if the
> header is missing?

If the header was missing then that would already be causing a
compilation failure. The issue with this particular version of
SPARC glibc is that the header is present but doesn't declare the
function.

Looking for EPOLLIN isn't a useful test for "is epoll_create1()
present and OK?" because:
(1) EPOLLIN will be defined on systems which only have epoll_create(),
so "is EPOLLIN present?" can be true when "is epoll_create1() OK?" is false
(2) we don't ever actually use EPOLLIN, so checking for it could
potentially cause us to not use epoll_create1() even if it was
present and usable

-- PMM