--- On Mon, 2/4/08, James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
I guess the same could be said for STGT and SCST, right?
LOL, no seriously, this is unnecessary kernel bloat,
or rather at the wrong place (see below).
But it would be trivial exercise to show that an
inconsistent state can be had by modifying pages
of the SES device directly from userspace bypassing
your implementation.
I've non at the moment, plus I don't think you'd be
the point of contact for a user-space SES library.
Unless of course you've already started something up
on sourceforge.
Really, such an effort already exists: it is called
sg_ses(8).
Yes, for which the transport layer, implements the
scsi device node for the SES device. It doesn't really
matter if the SCSI commands sent to the SES device go
over SGPIO or FC or SAS or Bluetooth or I2C, etc, the
transport layer can implement that and present the
/dev/sgX node.
Case in point: the protocol FW running on the ASIC
provides this capability so really the LLDD would
only see a the pure SCSI SES or processor device and
register that with the kernel. At which point no new
kernel bloat is required.
Your code doesn't quite do that at the moment as it
actually goes further in to read and present SES pages.
Ideally it would simply provide capability for transport
layers to register a SCSI device of type SES, or processor.
Architecturally, the LLDD/transport layer would register
the SGPIO device on one end with the SGPIO layer and on
the other end as a SCSI SES/processpr device. After that
sg_ses(8) or sglib, fits the bill for user space applications.
See previous paragraph.
What is the protocol of those "rest" that you talk about?
At any rate, this capability lies in the kernel providing
a _device node_ -- not quite what your patch is doing.
Luben
--
