On Fri, 18 Jan 2008 18:16:34 -0600 James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > On Fri, 2008-01-18 at 09:41 -0800, Kristen Carlson Accardi wrote: > > On Fri, 18 Jan 2008 11:11:21 -0600 > > James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > On Fri, 2008-01-18 at 08:52 -0800, Kristen Carlson Accardi wrote: > > > > On Thu, 17 Jan 2008 16:50:42 -0600 > > > > James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > > On Tue, 2008-01-15 at 16:44 -0800, Kristen Carlson Accardi > > > > > wrote: > > > > > > Add Enclosure Management support to libata and ahci. > > > > > > > > > > > > This patch adds support for the LED protocol, as defined in > > > > > > the AHCI spec. It adds a generic em_message and em_type > > > > > > sysfs entry per host. It also adds a sw_activity field per > > > > > > existing drive. > > > > > > > > > > > > The em_message field can be used by the driver to take > > > > > > enclosure management commands from userspace. In the case > > > > > > of the LED protocol, writes and reads from em_message > > > > > > correspond to the LED message format as defined in the AHCI > > > > > > spec. > > > > > > > > > > > > em_message type is a read only file that displays the > > > > > > current enclosure management protocol that is used by the > > > > > > driver. > > > > > > > > > > > > sw_activity is used by drivers which support software > > > > > > controlled activity LEDs. It has the following valid values: > > > > > > > > > > > > 0 OFF - the LED is not activated on activity > > > > > > 1 BLINK_ON - the LED blinks on every 10ms when > > > > > > activity is detected. 2 BLINK_OFF - the LED is on > > > > > > when idle, and blinks off every 10ms when activity is > > > > > > detected. > > > > > > > > > > > > It's important to note that the user must turn sw_activity > > > > > > OFF it they wish to control the activity LED via the > > > > > > em_message file. > > > > > > > > > > One of the things we really need to do is to get some type of > > > > > generic enclosure support. I note that ahci support three > > > > > standard eclosure management protocols (SAF-TE, SES-2, > > > > > SFF-8485 SGPIO) as well as the one proprietary one you've > > > > > chosen to implement. Is that because no-one in the field has > > > > > actually connected AHCI up to anything supporting one of the > > > > > standard protocols? > > > > > > > > > > I'm looking at this from slightly the other way around: the > > > > > SAS protocol is virtually mandating SFF-8485 as the enclosure > > > > > protocol to the point that it's actually built into the sas > > > > > management protocol ... I was starting to wonder how we > > > > > should be taking advantage of this. > > > > > > > > > > The implementation probably should be generic (above SCSI or > > > > > IDE or ATA) but it would obviously need to tap into the > > > > > subsytem/transport/device specific pieces, so possibly block > > > > > looks to be the right place to start? > > > > > > > > > > James > > > > > > > > > > > > > > > > > > I originally thought to try to make a generic enclosure > > > > management framework that we could hook individual EM protocols > > > > into. Then I started to wonder why we needed to add knowledge > > > > of these protocols into the kernel. At least the AHCI hardware > > > > which I'm familiar with, has no need to know anything about the > > > > protocol. It abstracts everything into just a message. So, > > > > the design that I did in this patch does the same thing. You > > > > export the type of protocol the driver is configured to accept, > > > > then the message buffer and leave it up to user space to > > > > understand the individual protocol. This works for all > > > > supported EM protocols. As far as I can see, most of these > > > > management protocols are better suited to being implemented in > > > > user space anyway. > > > > > > It's one way to look at it, if we go with SFF-8485 and the AHCI > > > specific protocol. Basically both of them are only about flashing > > > LEDs. The SAF-TE and SES protocols are much more comprehensive > > > (and include things like environmental monitors, temperature, > > > fans, etc.). > > > > Even these though can be boiled down to read a message/write a > > message. > > That's true of almost every protocol in the end. I was thinking of > the abstraction. The messages lead to flashing lights in the > enclosures. They also have interactive knobs that users twiddle on > the other end. We really need a uniform user interface abstraction > for enclosures. > I guess I'm still not seeing why this abstraction needs to be in the kernel. Why can't it be a user space library with a generic buffer to send/receive messages. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
