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

--- On Tue, 2/5/08, James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

quoted

quoted

Wrong ... we don't export non-SCSI devices as

SCSI

quoted

quoted

(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

quoted

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.

quoted

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.

   Luben