From: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-scsi <linux-scsi@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
Mike Christie <michaelc@cs.wisc.edu>,
Hannes Reinecke <hare@suse.de>,
James Bottomley <James.Bottomley@suse.de>,
Boaz Harrosh <bharrosh@panasas.com>
Subject: Re: [PATCH 0/4] tcm: Unify virtual subsystem plugin emulation code
Date: Mon, 11 Oct 2010 12:56:51 -0700 [thread overview]
Message-ID: <1286827011.20358.35.camel@haakon2.linux-iscsi.org> (raw)
In-Reply-To: <20101010073202.GA16772@lst.de>
On Sun, 2010-10-10 at 09:32 +0200, Christoph Hellwig wrote:
> What you did in this patch is a good step toward getting rid of the
> scsi logic in the backend, but it's quite enough yet. For one thing
> the backends really shouldn't know anything about scsi commands, so
> the call to transport_emulate_control_cdb should happen before even
> calling into the backend.
Hmmm, good point. I was trying to avoid doing this initially because it
adds more complexity when calling ->do_task() in target_core_transport.c
__transport_execute_tasks(), but I would agree the tradeoff here to make
IBLOCK, FILEIO and RAMDISK subsystem backend code SCSI control CDB
emulation independent is worth it.
> Second your ->emulate_foo callbacks still
> are far too SCSI-specific, e.g. WRITE SAME witht unmap bit and UNMAP
> emulation really should just go into a single ->discard callback
> for the backend. And instead of calling into the backend again for
> readcap emulation just set block_size and size attributs on a per-
> device object and let common code handle it. Similarly for inquity
> just set the device type and other variables and handle it in common
> code.
Ok, I think this makes sense and should be easy enough for the cases
that have been listed here. However, there are still cases (namely DIF)
that containing SCSI specific bits and would still be going into IBLOCK
and FILEIO.
> That avoid the special se_subsystem_api_cdb vector and simplifies
> the code a lot conceptually a lot. Together with calling
> transport_emulate_control_cdb directly from core code before going
> into ->do_task that does all the required work to make the backends
> independent of the scsi protocol, so we could also use it e.g.
> for ATA or virtio targets.
Makes sense, I will drop struct se_subsystem_api_cdb, et al and post a
followup patch series this afternoon.
Thanks!
--nab
next prev parent reply other threads:[~2010-10-11 20:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-10 3:48 [PATCH 0/4] tcm: Unify virtual subsystem plugin emulation code Nicholas A. Bellinger
2010-10-10 7:32 ` Christoph Hellwig
2010-10-11 19:56 ` Nicholas A. Bellinger [this message]
2010-10-12 19:00 ` Vladislav Bolkhovitin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1286827011.20358.35.camel@haakon2.linux-iscsi.org \
--to=nab@linux-iscsi.org \
--cc=James.Bottomley@suse.de \
--cc=bharrosh@panasas.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=michaelc@cs.wisc.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox