public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Douglas Gilbert <dougg@torque.net>
To: Bryan Henderson <hbryan@us.ibm.com>
Cc: Vladislav Bolkhovitin <vst@vlnb.net>,
	David Hollis <dhollis@davehollis.com>,
	dmitry_yus@yahoo.com,
	FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
	Guennadi Liakhovetski <g.liakhovetski@gmx.de>,
	iscsitarget-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
	Sander <sander@humilis.net>,
	Maciej Soltysiak <solt2@dns.toxicfilms.tv>
Subject: Re: SCSI/ISCSI, hardware/software
Date: Fri, 13 May 2005 14:55:02 +1000	[thread overview]
Message-ID: <42843326.3070000@torque.net> (raw)
In-Reply-To: <OFB07C63BD.91DCFD73-ON88256FFF.0065D9AA-88256FFF.006C4709@us.ibm.com>

Bryan Henderson wrote:
>>There is some confusion in the SCSI world between SCSI as a transport 
>>and SCSI as a commands set and software communication protocol, which 
>>works above the transport. So, you can implement SCSI transport at any 
>>software (eg iSCSI) or hardware (parallel SCSI, Fibre Channel, SATA, 
>>etc.) way, but if the SCSI message passing protocol is used overall 
>>system remains SCSI with all protocol obligations like task management. 
> 
> 
> The above doesn't really resolve the confusion, since it uses some 
> ambiguous terms and constructions.  I'm not sure what it's supposed to 
> say, but let me try to state in the terminology of the SCSI standards what 
> SCSI is:
> 
> SCSI is a family of separate specifications.  Some are specifications of 
> transports, and others are specifications of command sets (a layer above 
> the transports).  A SCSI device must implement a SCSI transport spec and a 
> SCSI command set spec -- and also contain a piece that actually does the 
> work (e.g. a disk drive), the details of which aren't specified by SCSI.
> 
> Examples of SCSI transport specification are (I'm paraphrasing the names) 
> parallel SCSI, Fibre Channel, and ISCSI.  Examples of command sets are the 
> disk device command set and the tape device command set.

Bryan,
This url might help to illustrate things:

http://t10.org/scsi-3.htm

Transports are below the yellow line, SCSI command sets
are above it.

Doug Gilbert

>>So, pure software SCSI solution is possible. BTW, there are pure 
>>hardware iSCSI implementations as well.
> 
> 
> I don't think it's even meaningful to talk about whether an implementation 
> is hardware or software.  The "pure hardware" implementations contain 
> megabytes of software, which was written in languages like C, contains 
> operating systems like Linux, and can be transmitted across a network and 
> updated easily.  The "pure software" implementation involve kilograms of 
> hardware in every SCSI command -- CPUs, power supplies, etc.
> 
> Not only that, but the "all hardware" ISCSI initiators people talk about, 
> which are PCI cards with Ethernet jacks, are not complete initiators.  The 
> computer you plug the card into, on which you run Linux and some 
> application programs, is the initiator.  The card is just the 
> ISCSI-specific core of it.
> 
> There's really two distinctions people mean to make when talking about 
> hardware vs software:
> 
> 1) Is it preassembled?  Can you lift it out of box whole, or do you have 
> to acquire some special software and some more generic parts separately 
> and manage their combination?
> 
> 2) Does it involve a general purpose computing system, particularly one 
> that you share with some other computing, or a faster special purpose 
> dedicated one?
> 
> In the context of a Linux SCSI discussion, I'd just talk about how much of 
> the implementation is in or above the Linux kernel, and how much is below. 
>  And then we can say that ISCSI-specific function (initiator or target) 
> can be implemented 1) entirely above the Linux kernel; 2) entirely inside 
> the Linux kernel; 3) entirely below the Linux kernel; or 4) a combination 
> of these.

  reply	other threads:[~2005-05-13  4:55 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1416215015.20050504193114@dns.toxicfilms.tv>
     [not found] ` <1115236116.7761.19.camel@dhollis-lnx.sunera.com>
     [not found]   ` <1104082357.20050504231722@dns.toxicfilms.tv>
     [not found]     ` <1115305794.3071.5.camel@dhollis-lnx.sunera.com>
     [not found]       ` <20050507150538.GA800@favonius>
2005-05-10 22:00         ` Re[2]: ata over ethernet question Guennadi Liakhovetski
2005-05-10 23:14           ` Dmitry Yusupov
2005-05-11  5:42             ` [Iscsitarget-devel] " FUJITA Tomonori
2005-05-11  8:56           ` Vladislav Bolkhovitin
2005-05-11 21:26             ` several messages Guennadi Liakhovetski
2005-05-12  2:16               ` Ming Zhang
2005-05-12 18:32                 ` Dmitry Yusupov
2005-05-13  8:12                   ` Christoph Hellwig
2005-05-13 15:04                     ` Dmitry Yusupov
2005-05-13 15:07                       ` Christoph Hellwig
2005-05-13 15:38                         ` Dmitry Yusupov
2005-05-12 10:17               ` Vladislav Bolkhovitin
2005-05-12 19:42                 ` SCSI/ISCSI, hardware/software Bryan Henderson
2005-05-13  4:55                   ` Douglas Gilbert [this message]
2005-05-13 10:34                   ` Vladislav Bolkhovitin
2005-05-13 23:58                     ` Bryan Henderson
2005-05-12 18:52           ` Re[2]: ata over ethernet question James Bottomley
2005-05-12 19:05             ` Dmitry Yusupov
2005-05-12 19:15               ` James Bottomley
2005-05-12 19:44                 ` Dmitry Yusupov
2005-05-13  8:16                   ` Christoph Hellwig
2005-05-13 16:18                     ` Dmitry Yusupov
2005-05-13  8:14               ` Christoph Hellwig
2005-05-13 18:50             ` iSCSI vs. NBD (was Re: ata over ethernet question) Guennadi Liakhovetski
2005-05-13 20:21               ` James Bottomley
2005-05-13 22:49                 ` Guennadi Liakhovetski
2005-05-25 23:41             ` NBD (vs. iSCSI vs. EATA vs...) Guennadi Liakhovetski
2005-05-26  1:19               ` James Bottomley
2005-05-26 17:48                 ` Guennadi Liakhovetski

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=42843326.3070000@torque.net \
    --to=dougg@torque.net \
    --cc=dhollis@davehollis.com \
    --cc=dmitry_yus@yahoo.com \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=g.liakhovetski@gmx.de \
    --cc=hbryan@us.ibm.com \
    --cc=iscsitarget-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=sander@humilis.net \
    --cc=solt2@dns.toxicfilms.tv \
    --cc=vst@vlnb.net \
    /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