From: Luben Tuikov <luben_tuikov@adaptec.com>
To: dougg@torque.net
Cc: Richard Bollinger <rabollinger@gmail.com>,
linux-scsi@vger.kernel.org, linux-ide@vger.kernel.org
Subject: Re: SATA Drive Information (vs hdparm -i)?
Date: Fri, 23 Sep 2005 10:22:47 -0400 [thread overview]
Message-ID: <43340FB7.3080708@adaptec.com> (raw)
In-Reply-To: <43334AFF.8010901@torque.net>
On 09/22/05 20:23, Douglas Gilbert wrote:
> However an improved "sdparm -i" is not what you seem to be
> asking for. Most of the above information is derived from
> the response to the IDENTIFY [PACKET] DEVICE ATA command.
> There seems to be two options for providing this:
> 1) libata to implement ioctls like HDIO_GET_IDENTITY
> 2) libata to implement SCSI ATA Translation [SAT]
> facilities such as:
> a) the ATA Information VPD page
> b) SCSI ATA pass through commands
> c) MODE SELECT SCSI command
>
> Option 1) is the simplest but it requires that the SAT layer
> is on the host computer [as it is in the case of libata].
> Hopefully external USB and Firewire storage enclosures will
> be enhanced to support the [draft] SAT standard and in
> that case the SAT layer will be in the enclosure. SATA
> disks [and S-ATAPI devices] in a SAS fabric may either
> tunnel through the SAS fabric [via SAS Tunnelling Protocol
> [STP]] or have a SAT layer in the fabric [typically in the
> enclosure holding the disks].
There will be no SAT layer in a SAS fabric. STP is just
that, a _tunneling_ protocol. Thus, either in Option 1,
or Option 2 if you want to present the device to
SCSI Core as a SCSI Device you need SAT somewhere below
SCSI Core (on the host).
In general, lower (hardware) layers want to do the
_absolute_ minimum as far as their function is concerned.
Thus, for example, you can expect an incomplete
USB/IEEE1394 SAT layer on the device.
> Only the STP route allows for option 1) .
Option 2 as well: you'll just treat the device as
SCSI and SAT will emulate as much as possible.
Luben
next prev parent reply other threads:[~2005-09-23 14:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-22 19:06 SATA Drive Information (vs hdparm -i)? Richard Bollinger
2005-09-23 0:23 ` Douglas Gilbert
2005-09-23 0:31 ` Randy.Dunlap
2005-09-23 1:01 ` Richard Bollinger
2005-09-23 1:14 ` Douglas Gilbert
2005-09-23 1:18 ` Richard Bollinger
2005-09-23 1:16 ` Ric Wheeler
2005-09-23 1:20 ` Randy.Dunlap
2005-09-23 1:33 ` Ric Wheeler
2005-09-23 1:06 ` Douglas Gilbert
2005-09-23 1:50 ` Mark Lord
2005-09-23 14:22 ` Luben Tuikov [this message]
2005-09-24 3:18 ` Douglas Gilbert
2005-09-25 14:56 ` Luben Tuikov
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=43340FB7.3080708@adaptec.com \
--to=luben_tuikov@adaptec.com \
--cc=dougg@torque.net \
--cc=linux-ide@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=rabollinger@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.