Re: Serial Attached SCSI Driver Interface (SDI)

[Jeff Garzik <jgarzik@pobox.com>]

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