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

[Blue Swirl]

On Tue, Apr 19, 2011 at 11:16 PM, Peter Maydell
<address@hidden> wrote:
> On 19 April 2011 20:59, Blue Swirl <address@hidden> wrote:
>> On Tue, Apr 19, 2011 at 10:48 PM, Peter Maydell
>> <address@hidden> wrote:
>>> On 19 April 2011 20:37, Blue Swirl <address@hidden> 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

Sorry, I just picked a define without much thought. A more specific
one would be flags parameter of epoll_create1(), like EPOLL_CLOEXEC or
EPOLL_NONBLOCK. We don't use them now since the target system call
argument is passed untranslated to host, but that is actually not
correct, since the bit definitions could be different. So checking for
one of those should be OK.