From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:37339)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1T8tXi-0000aR-28
	for qemu-devel@nongnu.org; Tue, 04 Sep 2012 09:51:55 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1T8tXe-0007Kj-4s
	for qemu-devel@nongnu.org; Tue, 04 Sep 2012 09:51:49 -0400
Received: from mx1.redhat.com ([209.132.183.28]:22498)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1T8tXd-0007Kf-T9
	for qemu-devel@nongnu.org; Tue, 04 Sep 2012 09:51:46 -0400
Message-ID: <50460765.1080007@redhat.com>
Date: Tue, 04 Sep 2012 15:51:33 +0200
From: Kevin Wolf <kwolf@redhat.com>
MIME-Version: 1.0
References: <1346663926-20188-1-git-send-email-xiawenc@linux.vnet.ibm.com>
	<1346663926-20188-5-git-send-email-xiawenc@linux.vnet.ibm.com>
	<5044BE96.7080701@redhat.com> <5044CA2F.8000505@redhat.com>
	<5045AA90.4050001@linux.vnet.ibm.com>
	<5045E84C.6030902@redhat.com> <504606D9.5070709@redhat.com>
In-Reply-To: <504606D9.5070709@redhat.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 4/6] libqblock internal used functions
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: stefanha@gmail.com, aliguori@us.ibm.com, Eric Blake <eblake@redhat.com>, Wenchao Xia <xiawenc@linux.vnet.ibm.com>, qemu-devel@nongnu.org

Am 04.09.2012 15:49, schrieb Paolo Bonzini:
> Il 04/09/2012 13:38, Eric Blake ha scritto:
>> Since qemu does not support it now, yes, you can ignore it for now.  But
>> please make sure that you aren't hard-coding it into the API - that is,
>> make sure that the API can someday grow to support larger sector sizes
>> with minimal impact to library clients (that is, that new clients aware
>> of the new API can target larger sector size once qemu has been patched
>> to support larger sector size).
> 
> We can support 4k sector disks even if the addressing unit remains 512
> bytes, just like in the Linux kernel.

Why should we even use an arbitrary unit like 512 bytes for addressing?
To me using byte granularity everywhere makes more sense and is clearer.

Kevin