LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: James Smart <James.Smart@Emulex.Com>
To: ltuikov@yahoo.com
Cc: Kristen Carlson Accardi <kristen.c.accardi@intel.com>,
	James Bottomley <James.Bottomley@HansenPartnership.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: Wed, 13 Feb 2008 09:08:03 -0500	[thread overview]
Message-ID: <47B2F9C3.8070207@emulex.com> (raw)
In-Reply-To: <875344.96222.qm@web31808.mail.mud.yahoo.com>

The keep-it-in-user-space arguments seem fairly compelling to me.
Especially as we've pushed whole i/o subsystems out to user space
(iscsi, stgt, talked about fcoe, a lot of dm control, etc).

The functionality seems to align with Doug's sg/lsscsi utility chain
as well.  Granted, the new utility would have to be designed in such
as way that it can incorporate vendor "hardware handlers".  But, if
James has a somewhat common implementation already for a kernel
implementation, I'm sure that can be the starting point for lsscsi.

So, the main question I believe is being asked is:
- Do we need to represent this via the object/sysfs tree or can an
   outside utility be depended upon to show it ?

Note that I am not supporting:
"Vendors may choose to distribute their own applications".
For this to become truly useful, there needs to be a common tool/method
that presents common features in a common manner, regardless of whether
it is in kernel or not.

-- james s


Luben Tuikov wrote:
> Which is already the case without the SES kernel bloat.
> Case in point, the excellent user-space application
> "lsscsi" would clearly show which device is SES.
> 
> And the excellent user-space application "sg_ses" could
> control an SES device.
> 
>> The pieces I think are absolutely standard are
>>
>> 1. Actual enclosure presence (is this device in an
>> enclosure)
> 
> "lsscsi"
> 
>> 2. Activity LED, this seems to be a feature of every
>> enclosure.
> 
> So that means that it needs a kernel representation?
> If this indeed were the case, for every "feature" of every
> type of device (not only SCSI) then the kernel itself would
> be insurmountably big.
> 
>> 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).
> 
> And none of this means that it needs a kernel representation.
> 
> 1. You're not "standardizing" any known, in-practice,
> kernel representation, that is already in practice and
> thusly needs a kernel representation.
> 
> 2. The kernel itself is not using nor needing this
> "representation" in order to function properly (the kernel).
> 
> Leaving control of SES devices to user-space makes both
> the kernel and the vendors happy.  All the kernel needs
> to do is expose the SES device to user-space as it currently
> does.  It makes it so much easier both to vendors and to
> the kernel to stay out of unnecessary representations.
> 
> Vendors may choose to distribute their own applications
> to control their hardware, as long as the kernel exposes
> an SES device and provides functionality, as opposed to
> policy of any kind.
> 
>     Luben
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

  reply	other threads:[~2008-02-13 14:08 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
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 [this message]
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=47B2F9C3.8070207@emulex.com \
    --to=james.smart@emulex.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=jeff@garzik.org \
    --cc=kristen.c.accardi@intel.com \
    --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).