LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: ltuikov@yahoo.com, linux-scsi <linux-scsi@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-ide <linux-ide@vger.kernel.org>,
	jeff@garzik.org
Subject: Re: [PATCH] enclosure: add support for enclosure services
Date: Tue, 12 Feb 2008 11:07:52 -0800	[thread overview]
Message-ID: <20080212110752.21840627@appleyard> (raw)
In-Reply-To: <1202841935.3137.94.camel@localhost.localdomain>

On Tue, 12 Feb 2008 12:45:35 -0600
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

> On Tue, 2008-02-12 at 10:22 -0800, Kristen Carlson Accardi wrote:
> > I apologize for taking so long to review this patch.  I obviously
> > agree wholeheartedly with Luben.  The problem I ran into while
> > trying to design an enclosure management interface for the SATA
> > devices is that there is all this vendor defined stuff.  For
> > example, for the AHCI LED protocol, the only "defined" LED is
> > 'activity'.  For LED2 and LED3 it is up to hardware vendors to
> > define these.  For SGPIO there's all kinds of ways for hw vendors
> > to customize.  I felt that it was going to be a maintainance
> > nightmare to have to keep track of various vendors enclosure
> > implementations in the ahci driver, and that it'd be better to just
> > have user space libraries take care of that.  Plus, that way a
> > vendor doesn't have to get a patch into the kernel to get their new
> > spiffy wizzy bang blinky lights working (think of how long it takes
> > something to even get into a vendor kernel, which is what these
> > guys care about...).  So I'm still not sold on having an enclosure
> > abstraction in the kernel - at least for the SATA controllers.
> 
> Correct me if I'm wrong, but didn't the original AHCI enclosure patch
> expose activity LEDs via sysfs?

You are sort of wrong.  we exposed a sysfs entry to enable sofware
controlled activity LED, then the driver was responsible for turning it
on and off. (blech, I know, but some vendors want this feature).

> 
> I'm not saying there aren't a lot of non standard pieces that need to
> be activated by direct commands or other user activated protocol.  I
> am saying there are a lot of standard pieces that we could do with
> showing in a uniform manner.
> 
> The pieces I think are absolutely standard are
> 
> 1. Actual enclosure presence (is this device in an enclosure)
> 2. Activity LED, this seems to be a feature of every enclosure.
> 
> I also think the following are reasonably standard (based on the fact
> that most enclosure standards recommend but don't require this):
> 
> 3. Locate LED (for locating the device).  Even if you only have an
> activity LED, this is usually done by flashing the activity LED in a
> well defined pattern.
> 4. Fault.  this is the least standardised of the lot, but does seem to
> be present in about every enclosure implementation.
> 
> All I've done is standardise these four pieces ... the services
> actually take into account that it might not be possible to do
> certain of these (like fault).
> 
> James
> 
> 

I understand what you are trying to do - I guess I just doubt the value
you've added by doing this.  I think that there's going to be so much
customization that system vendors will want to add, that they are going
to wind up adding a custom library regardless, so standardising those
few things won't buy us anything.


  reply	other threads:[~2008-02-12 19:15 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-03 21:40 James Bottomley
2008-02-03 22:03 ` Sam Ravnborg
2008-02-04  0:16   ` James Bottomley
2008-02-06  0:12     ` Andrew Morton
2008-02-06  2:57       ` James Bottomley
2008-02-05  0:32 ` Luben Tuikov
2008-02-05  0:41   ` James Bottomley
2008-02-05  2:01     ` Luben Tuikov
2008-02-05  2:14       ` James Bottomley
2008-02-05  3:28         ` Luben Tuikov
2008-02-05  4:37           ` James Bottomley
2008-02-05  5:35             ` Luben Tuikov
2008-02-05 15:01               ` James Bottomley
2008-02-05 19:33                 ` Luben Tuikov
2008-02-05 20:29                   ` James Bottomley
2008-02-05 20:39                     ` Luben Tuikov
2008-02-12 18:22       ` Kristen Carlson Accardi
2008-02-12 18:45         ` James Bottomley
2008-02-12 19:07           ` Kristen Carlson Accardi [this message]
2008-02-12 19:28             ` James Bottomley
2008-02-13 17:45               ` Kristen Carlson Accardi
2008-02-13 18:17                 ` James Bottomley
2008-02-16 12:44                 ` Pavel Machek
2008-02-13  9:48           ` Luben Tuikov
2008-02-13 14:08             ` James Smart
2008-02-13 16:04               ` James Bottomley
2008-02-13 16:22                 ` James Smart
2008-02-13 16:43                   ` James Bottomley
2008-02-13 16:49                     ` James Smart
2008-02-12 19:45         ` Luben Tuikov
2008-02-13 11:15 Luben Tuikov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080212110752.21840627@appleyard \
    --to=kristen.c.accardi@intel.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=jeff@garzik.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=ltuikov@yahoo.com \
    --subject='Re: [PATCH] enclosure: add support for enclosure services' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).