[lkml]   [2008]   [Feb]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] enclosure: add support for enclosure services
    --- On Tue, 2/5/08, James Bottomley <> wrote:
    > > > Wrong ... we don't export non-SCSI devices as
    > SCSI
    > > > (with the single and
    > > > rather annoying exception of ATA via SAT).
    > >
    > > I didn't say you should do that. I had already
    > > mentioned that vendors export such controls
    > > as either enclosure or processor type devices,
    > > and this is why I told you that that is what
    > > needs to be exported, which incidentally is
    > > a device node of that type.
    > >
    > > Without a common usage model already in the kernel
    > > to abstract (e.g. sd for block device, since you
    > brought
    > > that up) your abstraction seems redundant and
    > arbitrary.
    > Exactly, so the first patch in this series (a while ago

    See last paragraph.

    > now) was a
    > common usage model abstraction of enclosures, and the
    > second was an
    > implementation in terms of SES. I will do one in terms of
    > SGPIO as
    > well ... assuming I ever find a SGPIO enclosure ...

    The vendor would've abstracted that away most commonly
    using SES.

    > > Your kernel code already uses READ DIAGNOSTIC, etc,
    > > and I'd rather leave that to user-space.
    > You can do it in user space as well. It's just a bit
    > difficult to get
    > information out of a SES enclosure without using it, and
    > getting some of
    > the information is a requirement of the abstraction.

    You missed my point. Your abstraction is redundant and
    arbitrary -- it is not based on any known, in-practice,
    usage model, already in place that needs a better, common
    way of doing XYZ, and therefore needs an abstraction.


     \ /
      Last update: 2008-02-05 21:49    [W:0.049 / U:10.956 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site