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: [email protected]
> Cc: [email protected]; 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 [email protected]
> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |