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-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
