On 19 April 2011 20:59, Blue Swirl <blauwir...@gmail.com> wrote: > On Tue, Apr 19, 2011 at 10:48 PM, Peter Maydell > <peter.mayd...@linaro.org> wrote: >> On 19 April 2011 20:37, Blue Swirl <blauwir...@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