From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33182) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vz4nV-0002qe-SN for qemu-devel@nongnu.org; Fri, 03 Jan 2014 08:28:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vz4nP-0001F5-P4 for qemu-devel@nongnu.org; Fri, 03 Jan 2014 08:28:21 -0500 Message-ID: <52C6BAD8.3000107@redhat.com> Date: Fri, 03 Jan 2014 14:27:52 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1382099622-87967-1-git-send-email-nwhitehorn@freebsd.org> <46A0A8D3-7588-4C43-9137-67AE089FAEAB@suse.de> <52C5AEB0.5090505@freebsd.org> In-Reply-To: <52C5AEB0.5090505@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Nathan Whitehorn Cc: qemu-ppc , Alexander Graf , QEMU Developers 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