On 09/30/05 12:26, Andrew Patterson wrote:
>
> I talked to one of the authors of these specs. SDI is an attempt to
> create an open standard for the somewhat proprietary CSMI spec developed
> by HP. It is currently languishing in t10 due to the IOCTL problem you
> describe below (the "no new IOCTL's" doctrine caught them by surprise).
> There is some thought to going to a write()/read() on a character device
> model, but this has various problems as well.
I think that read/write from a char device is going away too.
For this reason I showed the whole picture of the SAS
domain in sysfs _and_ created a binary file attr to
send/receive SMP requests/responses to control
the domain and get attributes ("smp_portal" binary
attr of each expander).
It is completely user space driven and a user space library
is simple to write.
See drivers/scsi/sas/expander_conf.c which is a user
space utility. For the output see Announcement 3:
http://linux.adaptec.com/sas/Announce_2.txt or here:
http://marc.theaimsgroup.com/?l=linux-scsi&m=112629509318354&w=2
The code which implements it is very tiny, at the bottom
of drivers/scsi/sas/sas_expander.c
>>Sorry, did I mention "ioctl",
>>oh that makes SDI unacceptable. Almost a year ago that is what
>>happened to the first proposed SAS driver for Linux.
>
>
> That was one of the reasons the MPT Fusion and Adaptec drivers were
> rejected. There were others as well, such as lack of a SAS transport
> class.
You mean the first Adaptec SAS "adp94xx" driver.
BTW, neither the original "adp94xx", nor the subsequent "aic94xx"
Adaptec drivers implmented _any_ ioctls for CSMI/SDI.
Luben
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
