From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NANK7-0004t5-7O
	for qemu-devel@nongnu.org; Tue, 17 Nov 2009 07:38:19 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NANK5-0004ql-Fz
	for qemu-devel@nongnu.org; Tue, 17 Nov 2009 07:38:18 -0500
Received: from [199.232.76.173] (port=42884 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NANK4-0004pz-Oo
	for qemu-devel@nongnu.org; Tue, 17 Nov 2009 07:38:16 -0500
Received: from bhuna.collabora.co.uk ([93.93.128.226]:53555)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <ian.molton@collabora.co.uk>) id 1NANK4-0003Ys-CY
	for qemu-devel@nongnu.org; Tue, 17 Nov 2009 07:38:16 -0500
Received: from [192.168.1.64] (94-192-117-31.zone6.bethere.co.uk
	[94.192.117.31])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by bhuna.collabora.co.uk (Postfix) with ESMTPSA id 1ABAF600423
	for <qemu-devel@nongnu.org>; Tue, 17 Nov 2009 12:38:14 +0000 (GMT)
Message-ID: <4B029916.6000809@collabora.co.uk>
Date: Tue, 17 Nov 2009 12:37:42 +0000
From: Ian Molton <ian.molton@collabora.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] OPT_SIZE parsing
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

Hi,

Qemu currently is making a bit of a hash of parsing suffixes,

Right now, it has:

T, G, M, and K  which are multiples of 1024 bytes - fair enough

but it also has:

k - 1024  (should be 1000)

and b:

Byte (also wrong)

since its only using a single character, with b taken, theres no way to
represent 'bit' unless I use B, which is a bit, well daft.

Would there be any issues if this was updated to parse
[T,t,G,g,M,m,K,k,][,B,b] type syntax, so we could have things like Kb
and MB for Kbits and Megabytes respectively ?