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