From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43704) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2Td4-0001OS-TS for qemu-devel@nongnu.org; Sun, 12 Jan 2014 17:35:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W2Tcx-0005Pl-Ig for qemu-devel@nongnu.org; Sun, 12 Jan 2014 17:35:38 -0500 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Message-id: <52D318B1.8020906@freebsd.org> Date: Sun, 12 Jan 2014 17:35:29 -0500 From: Nathan Whitehorn References: <1382099622-87967-1-git-send-email-nwhitehorn@freebsd.org> <46A0A8D3-7588-4C43-9137-67AE089FAEAB@suse.de> <52C5AEB0.5090505@freebsd.org> <52C6BAD8.3000107@redhat.com> In-reply-to: <52C6BAD8.3000107@redhat.com> Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH] spapr_vscsi: Fix REPORT_LUNS handling List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-ppc , Alexander Graf , QEMU Developers On 01/03/14 08:27, Paolo Bonzini wrote: > Il 02/01/2014 19:23, Nathan Whitehorn ha scritto: >>>> Let me try to grasp what you're doing here. You're trying to >>>> figure out how many devices there are attached to the bus. For >>>> every device you reserve a buffer block. Lun0 is mandatory, all >>>> others are optional. >>>> >>>> First off, I think the code would be easier to grasp if you'd >>>> count "number of entries" rather than "number of bytes". That way >>>> we don't have to mentally deal with the 8 byte block >>>> granularity. >>>> >>>> Then IIUC you're jumping through a lot of hoops to count lun0 if >>>> it's there, but keep it reserved when it's not there. Why don't >>>> you just always reserve entry 0 for lun0? In the loop where >>>> you're actually filling in data you just skip lun0. Or is lun0 a >>>> terminator and always has to come last? > This is simply because you should not report lun 0 twice; even if it is > not defined, LUN 0 is there as a dummy device that only answers a > handful of commands (including INQUIRY and REPORT LUNS). There are many > ways to write it, but unless you use GArray or something like that, it > will look very much like Nathan and hw/scsi/scsi-bus.c's code. > > Paolo I've sent a new version of this patch reflecting the discussion here. Please let me know if I have missed anything. -Nathan