[lkml]   [2008]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] enclosure: add support for enclosure services
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
> More majordomo info at

 \ /
  Last update: 2008-02-13 15:11    [W:0.142 / U:2.052 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site