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.
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
-
: 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
