From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46608) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Swx9K-0005ZI-3e for qemu-devel@nongnu.org; Thu, 02 Aug 2012 11:17:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Swx9E-00037x-Bn for qemu-devel@nongnu.org; Thu, 02 Aug 2012 11:17:18 -0400 Received: from mail-gh0-f173.google.com ([209.85.160.173]:60130) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Swx9E-00037t-7Q for qemu-devel@nongnu.org; Thu, 02 Aug 2012 11:17:12 -0400 Received: by ghrr14 with SMTP id r14so8531129ghr.4 for ; Thu, 02 Aug 2012 08:17:11 -0700 (PDT) Sender: Richard Henderson Message-ID: <501A99F5.9080603@twiddle.net> Date: Thu, 02 Aug 2012 08:17:09 -0700 From: Richard Henderson MIME-Version: 1.0 References: <1343254238-4727-1-git-send-email-rth@twiddle.net> <1343254238-4727-5-git-send-email-rth@twiddle.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 04/10] linux-user: Sync fcntl.h bits with the kernel List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: riku.voipio@iki.fi, qemu-devel@nongnu.org On 2012-08-02 07:34, Peter Maydell wrote: > No entries for TARGET_M68K? I checked and I think that's the > only supported arch which isn't listed here and isn't only using > the asm-generic values. (It's the same 4 defines as TARGET_ARM.) I didn't notice because it was missing beforehand. > The other targets were all straightforward to review but I had a > little difficulty with the Alpha bits here. > (1) O_LARGEFILE is 0 here but not in the kernel. Does the "not > necessary" comment here mean "not necessary for QEMU" ? > (ie is the difference because we are taking a different approach to > the kernel's "always set this bit on entry" one ?) Yes. The fact that the kernel forces O_LARGEFILE set means that from an ABI perspective it might as well be zero. The fact that it is defined to non-zero in kernel headers is merely historical, and probably to document that the bit was used once. > > (2) where has the TARGET_FASYNC entry come from? You mean why isn't it using the default below? Good question... r~