From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1N7Uc4-0002nb-5v
	for qemu-devel@nongnu.org; Mon, 09 Nov 2009 08:48:56 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1N7Ubz-0002md-LI
	for qemu-devel@nongnu.org; Mon, 09 Nov 2009 08:48:55 -0500
Received: from [199.232.76.173] (port=38028 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1N7Ubz-0002mS-Gm
	for qemu-devel@nongnu.org; Mon, 09 Nov 2009 08:48:51 -0500
Received: from mx1.redhat.com ([209.132.183.28]:25831)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@redhat.com>) id 1N7Ubz-0005zD-1n
	for qemu-devel@nongnu.org; Mon, 09 Nov 2009 08:48:51 -0500
Message-ID: <4AF81DBF.2070002@redhat.com>
Date: Mon, 09 Nov 2009 15:48:47 +0200
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [sneak preview] major scsi overhaul
References: <4AF4ACA5.2090701@redhat.com>	<f43fc5580911070722n415ea07cr63c2816263234df@mail.gmail.com>
	<4AF7DC02.2070308@redhat.com> <4AF80CFF.1090607@redhat.com>
	<4AF81329.5030904@redhat.com> <4AF81670.6040500@redhat.com>
	<4AF81B8C.5040105@redhat.com>
In-Reply-To: <4AF81B8C.5040105@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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: Gerd Hoffmann <kraxel@redhat.com>
Cc: Blue Swirl <blauwirbel@gmail.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>

On 11/09/2009 03:39 PM, Gerd Hoffmann wrote:
>   Hi,
>
>>> Doesn't fly. Either every SCSI HBA uses QEMUSG64List (thus making this
>>> aequivalent to the next option from the scsi point of view), or
>>> scsi-disk would have to support both formats.
>>
>> A device or device set which is always 64-bit would always use
>> QEMUSG64List. A device which is always 32-bit would use QEMUSG32List.
>
> A scsi-disk can be connected to both 32-bit and 64-bit HBAs though ...
>

A line has to be drawn.  Since we have a limited number of HBAs, and 
since the performance impact will be minimal, we can safely use 64-bit 
for scsi.

-- 
error compiling committee.c: too many arguments to function