Serial Attached SCSI Driver Interface (SDI)

Serial Attached SCSI Driver Interface (SDI)

[Luben Tuikov]

I think it would be a good thing:

ftp://ftp.t10.org/t10/document.04/04-345r1.pdf

	Luben

P.S. CSMI...

Re: Serial Attached SCSI Driver Interface (SDI)

[Jeff Garzik]

Luben Tuikov wrote:
> I think it would be a good thing:
> 
> ftp://ftp.t10.org/t10/document.04/04-345r1.pdf
> 
>     Luben
> 
> P.S. CSMI...

What sort of interface is this?

Hardware interface?  Software-based (ioctl) interface?

	Jeff

RE: Serial Attached SCSI Driver Interface (SDI)

[Moore, Eric Dean]

How are you planning to support CSMI?

I have already submitted drivers last week
on this mailing list with CSMI support, 
and it was rejected by Christoph, Arjan, 
and Company.

Eric Moore
LSI Logic


On Monday, November 15, 2004 10:22 AM, Luben Tuikov wrote:
> 
> I think it would be a good thing:
> 
> ftp://ftp.t10.org/t10/document.04/04-345r1.pdf
> 
> 	Luben
> 
> P.S. CSMI...
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

RE: Serial Attached SCSI Driver Interface (SDI)

[Salyzyn, Mark]

CSMI is an ioctl mechanism. Have incorporated this interface into my
working version of the driver. Duplication is already showing, witness
Eric Moore's (rejected) submission.

The T10 document Luben refers to, is to start the groundwork and does
not list any specific interface yet. March 2006 is the `public release
data' ... Get your comments in now!

Sincerely -- Mark Salyzyn

-----Original Message-----
From: linux-scsi-owner@vger.kernel.org
[mailto:linux-scsi-owner@vger.kernel.org] On Behalf Of Jeff Garzik
Sent: Monday, November 15, 2004 12:40 PM
To: Tuikov, Luben
Cc: SCSI Mailing List
Subject: Re: Serial Attached SCSI Driver Interface (SDI)

Luben Tuikov wrote:
> I think it would be a good thing:
> 
> ftp://ftp.t10.org/t10/document.04/04-345r1.pdf
> 
>     Luben
> 
> P.S. CSMI...

What sort of interface is this?

Hardware interface?  Software-based (ioctl) interface?

	Jeff



-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Serial Attached SCSI Driver Interface (SDI)

[Jeff Garzik]

Salyzyn, Mark wrote:
> CSMI is an ioctl mechanism. Have incorporated this interface into my
> working version of the driver. Duplication is already showing, witness
> Eric Moore's (rejected) submission.
> 
> The T10 document Luben refers to, is to start the groundwork and does
> not list any specific interface yet. March 2006 is the `public release
> data' ... Get your comments in now!


ug.

These ioctl mechanisms almost always (a) have design flaws [which cannot 
be corrected, since they are in a spec] and (b) duplicate other 
functionality of the Linux kernel.  The SNIA ioctl mess is a great 
example of this.

Without any additional info, my first reaction is that this is yet more 
stuff Linux doesn't need.

	Jeff

RE: Serial Attached SCSI Driver Interface (SDI)

[Salyzyn, Mark]

For a) design flaw, probably, but a cross-OS standard is still better
than nothing. One built-in design flaw is that a standard will
necessarily be a subset of the needs of the users and the various
management applications.

For b) So, there is a standard Hardware RAID management ioctl mechanism
in Linux? The duplication has all been going into each and every H/W
RAID card's driver.

The goals of most H/W RAID card's management passthrough functions
invariably bends to the purposes of the management application needs and
the underlying Firmware architecture. Bridging application space into
the driver has also been cross purpose to the goals of the OS internals
designers.

What is needed is that we all come to an agreement as to the necessity
for management application passthrough into the Firmware. Once we have
that, maybe a standard that makes sense in the scsi core can take root.

Sincerely -- Mark Salyzyn

-----Original Message-----
From: Jeff Garzik [mailto:jgarzik@pobox.com] 
Sent: Monday, November 15, 2004 1:02 PM
To: Salyzyn, Mark
Cc: Tuikov, Luben; SCSI Mailing List; Eric.Moore@lsil.com
Subject: Re: Serial Attached SCSI Driver Interface (SDI)

Salyzyn, Mark wrote:
> CSMI is an ioctl mechanism. Have incorporated this interface into my
> working version of the driver. Duplication is already showing, witness
> Eric Moore's (rejected) submission.
> 
> The T10 document Luben refers to, is to start the groundwork and does
> not list any specific interface yet. March 2006 is the `public release
> data' ... Get your comments in now!


ug.

These ioctl mechanisms almost always (a) have design flaws [which cannot

be corrected, since they are in a spec] and (b) duplicate other 
functionality of the Linux kernel.  The SNIA ioctl mess is a great 
example of this.

Without any additional info, my first reaction is that this is yet more 
stuff Linux doesn't need.

	Jeff

Re: Serial Attached SCSI Driver Interface (SDI)

[Luben Tuikov]

Jeff Garzik wrote:
> ug.
> 
> These ioctl mechanisms almost always (a) have design flaws [which cannot 
> be corrected, since they are in a spec] and (b) duplicate other 
> functionality of the Linux kernel.  The SNIA ioctl mess is a great 
> example of this.
> 
> Without any additional info, my first reaction is that this is yet more 
> stuff Linux doesn't need.

I don't want to speculate on whether it will or not be an ioctl
mechanism.  But most importantly, by architecture design, SAS
really _needs_ a control management infrastructure of its components
and _maybe_ a representation somewhere in the OS.  Since it really
represents a "storage network" and in certain instances a complicated
one at that.

That control management infrastructure would be shared by (used by
both) the OS and the kernel (for the appropriate functionaly needed/provided).

I've just got official word that SDI would be "the industry
standard version of CSMI".

It's a good thing,
	Luben

Re: Serial Attached SCSI Driver Interface (SDI)

[Jeff Garzik]

Luben Tuikov wrote:
> I don't want to speculate on whether it will or not be an ioctl
> mechanism.  But most importantly, by architecture design, SAS
> really _needs_ a control management infrastructure of its components
> and _maybe_ a representation somewhere in the OS.  Since it really
> represents a "storage network" and in certain instances a complicated
> one at that.
> 
> That control management infrastructure would be shared by (used by
> both) the OS and the kernel (for the appropriate functionaly 
> needed/provided).


Please don't misunderstand.  I certainly agree that a management 
infrastructure is needed, and yes, having a common one is preferred to 
having a different one in each driver.

I however disagree that this commonality can be factored out by 
committee (specification) that has no knowledge of Linux.  The motto of 
Linux is, "do what you must, and no more."  If you look at the history 
of Linux, _any_ time an API has been imposed upon Linux, inherent API 
disconnects appear almost immediately.

I would much rather see a sysfs interface (transport class like James is 
proposing) that specifies "knobs" (controls) needed under Linux... 
controls that are presumably not redundant to a pre-existing Linux 
knobs.  If you need 2.4.x compatibility, a driver can easily interface 
with a common 2.4.x "libfs" filesystem module.

This applies whether we are talking about RAID management or storage 
network management or SATA/SAS phy management.  Create a _Linux_ 
management interface that is common across vendors and drivers.

T10, SNIA, and all the other storage industry committees have a _zero_ 
percent track record for doing OS software APIs correctly.

Commonality: good.  API imposed upon Linux by non-Linux committee:  bad.

You can't write a Linux API without knowing Linux-related issues.

	Jeff

Re: Serial Attached SCSI Driver Interface (SDI)

[Luben Tuikov]

Jeff Garzik wrote:
> Please don't misunderstand.  I certainly agree that a management 
> infrastructure is needed, and yes, having a common one is preferred to 
> having a different one in each driver.
> 
> I however disagree that this commonality can be factored out by 
> committee (specification) that has no knowledge of Linux.  The motto of 
> Linux is, "do what you must, and no more."  If you look at the history 
> of Linux, _any_ time an API has been imposed upon Linux, inherent API 
> disconnects appear almost immediately.
> 
> I would much rather see a sysfs interface (transport class like James is 
> proposing) that specifies "knobs" (controls) needed under Linux... 
> controls that are presumably not redundant to a pre-existing Linux 
> knobs.  If you need 2.4.x compatibility, a driver can easily interface 
> with a common 2.4.x "libfs" filesystem module.
> 
> This applies whether we are talking about RAID management or storage 
> network management or SATA/SAS phy management.  Create a _Linux_ 
> management interface that is common across vendors and drivers.
> 
> T10, SNIA, and all the other storage industry committees have a _zero_ 
> percent track record for doing OS software APIs correctly.
> 
> Commonality: good.  API imposed upon Linux by non-Linux committee:  bad.
> 
> You can't write a Linux API without knowing Linux-related issues.

Hey Jeff,

I completely agree with you.  Minimalistic approach is a good thing.

As to the API: the more reason for knowlegable Linux folks to keep
an "eye" on SDI and other relevant developing standards.
This way there'd be yet another voice of experience (Linux).

Getting the design right is very important.  IMO, I think it'd
better to have OS independence (SDI) as opposed to "Windows, Linux
and other OSs are addressed" (pre-SDI).

I can envision a complete SAS domain representation somewhere
behind /sys, including phys, expanders and devices, all based
upon SDI, transparent to userspace.  That is, "if you want to
control it, better represent it", so that each component of the
domain, would be representted and its "knobs".

	Luben

Re: Serial Attached SCSI Driver Interface (SDI)

[Jeff Garzik]

Luben Tuikov wrote:
> I completely agree with you.  Minimalistic approach is a good thing.
> 
> As to the API: the more reason for knowlegable Linux folks to keep
> an "eye" on SDI and other relevant developing standards.
> This way there'd be yet another voice of experience (Linux).
> 
> Getting the design right is very important.  IMO, I think it'd
> better to have OS independence (SDI) as opposed to "Windows, Linux
> and other OSs are addressed" (pre-SDI).

I would prefer to see how a rough-draft Linux implementation would look 
first.  Otherwise, without an implementation, linux-scsi denizens don't 
really have a basis from which to form design input.  That's really the 
"Internet way" -- form a rough consensus based on [test | production] 
implementations, then write the standard.

This area is also a bit delicate politically, because various companies 
have various bits of "value-add" in their management utils.  This is 
delicate because it clashes with the Linux wish to be vendor-neutral.  A 
vendor-neutral "Linux-ish" management API (be it RAID or SAN or 
whatever) would strongly encourage existence of a vendor-neutral, open 
source management utility.


For a starting point...  basically the problem boils to:  you need a 
control point (/dev node, /sysfs file, ioctl, etc.) that allows you to 
create, destroy, and manipulate nodes [a.k.a. SCSI targets] and node 
attributes.  James seemed to favor creating a few transport classes 
(visible through sysfs) that could act as these control points.

I should dig up a RAID card somewhere, and see what I could do about a 
block-level RAID management API.  (thinking out loud, probably silly)

	Jeff

Re: Serial Attached SCSI Driver Interface (SDI)

[Jeff Garzik]

Salyzyn, Mark wrote:
> For a) design flaw, probably, but a cross-OS standard is still better
> than nothing. One built-in design flaw is that a standard will
> necessarily be a subset of the needs of the users and the various
> management applications.

also, one problem with cross-OS APIs is that they are a superset not a 
subset.

	Jeff