From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:57276)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <hare@suse.de>) id 1XjRC5-0007LZ-1u
	for qemu-devel@nongnu.org; Wed, 29 Oct 2014 07:13:43 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <hare@suse.de>) id 1XjRBz-0001fm-0j
	for qemu-devel@nongnu.org; Wed, 29 Oct 2014 07:13:37 -0400
Received: from cantor2.suse.de ([195.135.220.15]:33382 helo=mx2.suse.de)
	by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <hare@suse.de>)
	id 1XjRBy-0001fi-RC
	for qemu-devel@nongnu.org; Wed, 29 Oct 2014 07:13:30 -0400
Message-ID: <5450CBD9.7020807@suse.de>
Date: Wed, 29 Oct 2014 12:13:29 +0100
From: Hannes Reinecke <hare@suse.de>
MIME-Version: 1.0
References: <1414569232-21357-1-git-send-email-hare@suse.de>
	<1414569232-21357-6-git-send-email-hare@suse.de>
	<5450AE41.4030600@redhat.com>
In-Reply-To: <5450AE41.4030600@redhat.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [PATCH 05/17] scsi: Remove 'lun' argument
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>, qemu-devel@nongnu.org
Cc: Alexander Graf <agraf@suse.de>, Nic Bellinger <nab@datera.com>, Andreas Faerber <afaerber@suse.de>

On 10/29/2014 10:07 AM, Paolo Bonzini wrote:
> On 10/29/2014 08:53 AM, Hannes Reinecke wrote:
>> All scsi functions take a scsi device as argument, which has
>> a LUN assigned to it. So we can get rid of specifying the 'lun'
>> as separate argument.
>=20
> ... except if you are sending a command to a non-existent LUN, in which
> case scsi_req_new detects this and redirects to a special SCSIReqOps
> instance:
>=20
>     ... else if (lun !=3D d->lun ||
>                buf[0] =3D=3D REPORT_LUNS ||
>                (buf[0] =3D=3D REQUEST_SENSE && d->sense_len)) {
>         ops =3D &reqops_target_command;
>     } else {
>         ops =3D NULL;
>     }
>=20
> Yes, it's ugly.  If you have a better idea, I'm all ears.  Passing a
> NULL SCSIDevice is hard though.
>=20
But still can happen even with the current code.
Look at eg hw/scsi/esp.c:

    current_lun =3D scsi_device_find(&s->bus, 0, s->current_dev->id, lun)=
;
    s->current_req =3D scsi_req_new(current_lun, 0, buf, s);
    datalen =3D scsi_req_enqueue(s->current_req);

If scsi_device_find() returns NULL we're done for.
>>From what I've seeing we have two ways out of here:
- Make scsi_req_new accept NULL SCSIDevice pointer
- Make scsi_device_find() return a dummy device
  with type TYPE_NO_LUN.

The latter is more appealing, as then we wouldn't need to
update the parsing logic later on.

Cheers,

Hannes
--=20
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg
GF: J. Hawn, J. Guild, F. Imend=F6rffer, HRB 16746 (AG N=FCrnberg)