From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46438) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fMbt9-0003OB-8l for qemu-devel@nongnu.org; Sat, 26 May 2018 12:17:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fMbt8-0001Xq-C5 for qemu-devel@nongnu.org; Sat, 26 May 2018 12:17:51 -0400 Received: from mail-pl0-x243.google.com ([2607:f8b0:400e:c01::243]:40684) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fMbt8-0001XN-4a for qemu-devel@nongnu.org; Sat, 26 May 2018 12:17:50 -0400 Received: by mail-pl0-x243.google.com with SMTP id t12-v6so4829953plo.7 for ; Sat, 26 May 2018 09:17:50 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Keno Fischer Date: Sat, 26 May 2018 12:17:08 -0400 Message-ID: Content-Type: text/plain; charset="UTF-8" Subject: Re: [Qemu-devel] [PATCH 01/13] 9p: linux: Fix a couple Linux assumptions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= , QEMU Developers , Keno Fischer , Greg Kurz >>> diff --git a/fsdev/file-op-9p.h b/fsdev/file-op-9p.h >>> index 3fa062b..a13e729 100644 >>> --- a/fsdev/file-op-9p.h >>> +++ b/fsdev/file-op-9p.h >>> @@ -16,7 +16,9 @@ >>> >>> #include >>> #include >>> +#ifdef CONFIG_LINUX >> >> What about a less restrictive: >> >> #ifndef __APPLE__ > > In general I would recommend checking for specific > features (usually in configure), rather than adding > ifdef tests for particular OSes. In this case presumably > we're including these headers because we're after > a specific function or define or whatever, so we can > check in configure for what header that's in (or > if it's not available at all). > > thanks > -- PMM This header is used for struct statfs. I would be fine with a configure check for this, though it looks like other places in the code base that use this header (e.g. util/mmap-alloc.c) also guard it in CONFIG_LINUX, so that seemed like the right check to me given the current code base. Would you like me to submit a patch to switch these to a configure check?