Re: I request inclusion of SAS Transport Layer and AIC-94xx intothe kernel

[Luben Tuikov]

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



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/