Re: [PATCH] enclosure: add support for enclosure services

[James Smart]

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@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/