Thread (30 messages) 30 messages, 7 authors, 2008-02-19

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

From: James Bottomley <James.Bottomley@HansenPartnership.com>
Date: 2008-02-05 20:30:01
Also in: linux-scsi, lkml

On Tue, 2008-02-05 at 11:33 -0800, Luben Tuikov wrote:
quoted
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 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 ...
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.

James

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help