lkml.org 
[lkml]   [2008]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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 majordomo@vger.kernel.org
    > More majordomo info at http://vger.kernel.org/majordomo-info.html
    >


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