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

[Andrew Patterson]

On Fri, 2005-09-30 at 13:07 -0400, Salyzyn, Mark wrote:
> At the SAS BOF, I indicated that it would not be much trouble to
> translate the CSMI handler in the aacraid driver to a similar sysfs
> arrangement. If such info can be mined from a firmware based RAID card,
> every driver should be able to do so. The spec writers really need to
> consider rewriting SDI for sysfs (if they have not already) and move
> away from an ABI.

SDI is supposed to be a cross-platform spec, so mandating sysfs would
not work.  I suggested to the author to use a library like HPAAPI (used
by Fibre channel), so you could hide OS implementation details.  I am in
fact working on such a beasty (http://libsdi.berlios.de).  He thinks
that library solutions tend to not work, because the library version is
never in synch with the standard/LLDD's. Given Linux vendor lead-times,
he does have a valid point.

Note that a sysfs implementation has problems.  Binary attributes are
discouraged/not-allowed.  There is no atomic request/response
operations, buffers limited to page size, etc. Other alternatives are
configfs, SG_IO, and the above mentioned character device.  None are a
complete replacement for the transactional nature of IOCTL's.  A group
of us are looking into this.  We probably should be taking it to
linux-scsi, but didn't want to get it caught up in the current flamewar.

Andrew

> 
> Sincerely -- Mark Salyzyn
> 
> -----Original Message-----
> From: Tuikov, Luben
> Sent: Friday, September 30, 2005 12:47 PM
> To: andrew.patterson@xxxxxx
> Cc: dougg@xxxxxxxxxx; Linus Torvalds; Luben Tuikov; SCSI Mailing List;
> Linux Kernel Mailing List
> Subject: Re: I request inclusion of SAS Transport Layer and AIC-94xx
> into the kernel
> 
> 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
> -
> To unsubscribe from this list: 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
> 

-
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/