From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35511) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SS7ob-0001YF-Qo for qemu-devel@nongnu.org; Wed, 09 May 2012 10:24:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SS7oT-0007ac-K3 for qemu-devel@nongnu.org; Wed, 09 May 2012 10:24:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40704) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SS7oT-0007Xv-Cl for qemu-devel@nongnu.org; Wed, 09 May 2012 10:24:21 -0400 Message-ID: <4FAA7E10.5020206@redhat.com> Date: Wed, 09 May 2012 16:24:16 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1336488722-13120-1-git-send-email-pbonzini@redhat.com> <1336488722-13120-20-git-send-email-pbonzini@redhat.com> <4FAA73D7.3030203@redhat.com> <4FAA799B.9090606@redhat.com> <4FAA7AD2.3060308@redhat.com> In-Reply-To: <4FAA7AD2.3060308@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1.1 19/22] block: implement is_allocated for raw List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel@nongnu.org, stefanha@linux.vnet.ibm.com Il 09/05/2012 16:10, Kevin Wolf ha scritto: > > While SEEK_* is not guaranteed by POSIX to be 0/1/2, the values is so > > old that there may still exist programs that hard-code the values > > (similar to O_RDONLY/O_WRONLY/O_RDWR, though probably not any other O_* > > constant). It would be quite unwise to define them to something else. > > Even MS-DOS reused the values! > > > > AFAIK this is the only extension of lseek that's ever been added. It > > was done on Solaris first and then in Linux and the BSDs. It used 3/4 > > there too, see for example http://bugs.python.org/msg119551 (Solaris) > > and http://mail-index.netbsd.org/tech-kern/2011/08/17/msg011231.html > > (NetBSD). > > Why not simply #ifdef the whole code out and fall back to the current > "everything is allocated" behaviour when SEEK_DATA/HOLE aren't defined? That would be okay too of course. When I wrote it Google Code existed still, so I must have taken the idiom from some place. Now it doesn't anymore, so I cannot check and it's okay to keep it safe. The code is a little bit uglier though. Paolo