From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59552) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QCHLO-0002Wg-Jw for qemu-devel@nongnu.org; Tue, 19 Apr 2011 16:16:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QCHLN-0007rx-Gq for qemu-devel@nongnu.org; Tue, 19 Apr 2011 16:16:18 -0400 MIME-Version: 1.0 In-Reply-To: References: <1303203461-30776-1-git-send-email-peter.maydell@linaro.org> Date: Tue, 19 Apr 2011 21:16:16 +0100 Message-ID: From: Peter Maydell Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH] configure: Make epoll_create1 test work around SPARC glibc bug List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-trivial@nongnu.org, qemu-devel@nongnu.org, patches@linaro.org On 19 April 2011 20:59, Blue Swirl wrote: > On Tue, Apr 19, 2011 at 10:48 PM, Peter Maydell > wrote: >> On 19 April 2011 20:37, Blue Swirl 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