RE: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel
From: Salyzyn, Mark (mark_salyzyn_at_adaptec.com)
Date: 09/30/05
- Previous message: Christoph Lameter: "Re: 2.6.14-rc1-git-now still dying in mm/slab - this time line 1849"
- Maybe in reply to: Luben Tuikov: "I request inclusion of SAS Transport Layer and AIC-94xx into the kernel"
- Next in thread: Arjan van de Ven: "RE: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel"
- Reply: Arjan van de Ven: "RE: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel"
- Reply: Andrew Patterson: "RE: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 30 Sep 2005 13:07:27 -0400 To: "Tuikov, Luben" <Luben_Tuikov@adaptec.com>, <andrew.patterson@hp.com>
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@hp.com
Cc: dougg@torque.net; 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-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Previous message: Christoph Lameter: "Re: 2.6.14-rc1-git-now still dying in mm/slab - this time line 1849"
- Maybe in reply to: Luben Tuikov: "I request inclusion of SAS Transport Layer and AIC-94xx into the kernel"
- Next in thread: Arjan van de Ven: "RE: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel"
- Reply: Arjan van de Ven: "RE: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel"
- Reply: Andrew Patterson: "RE: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
