From: Christoph Hellwig <hch@lst.de>
To: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
Cc: linux-scsi <linux-scsi@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Christoph Hellwig <hch@lst.de>,
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: Sun, 10 Oct 2010 09:32:02 +0200 [thread overview]
Message-ID: <20101010073202.GA16772@lst.de> (raw)
In-Reply-To: <1286682498-4821-1-git-send-email-nab@linux-iscsi.org>
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. 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. 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.
next prev parent reply other threads:[~2010-10-10 7:32 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 [this message]
2010-10-11 19:56 ` Nicholas A. Bellinger
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=20101010073202.GA16772@lst.de \
--to=hch@lst.de \
--cc=James.Bottomley@suse.de \
--cc=bharrosh@panasas.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=hare@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=michaelc@cs.wisc.edu \
--cc=nab@linux-iscsi.org \
/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