> Hello all. Hello! > I'm a firmware engineer working on an expander inside an external > enclosure that supports SES. I have been using the sg interface > (/dev/sgXX) sg_ses and sg_write_buffer to communicate to my device > fine for some time now. > > Searching through the list archives, I found a thread from 2008 > discussing the ses.c kernel patch and associated /sys/ interface and > lack of /dev/ interface in that code. > > For my enclosure, the /sys/ interface is inadequate. It does not > appear to provide access to a SSP READ_BUFFER, WRITE_BUFFER or monitor > generic SES elements. (the enclosure provides SES monitoring of temp, > fans and PSU voltages) > > > What I would like to see is a /dev/sesXX mapping such that the I, and > my soon to come ses monitoring apps don't have to search through the > /dev/sgXX system to find the SES devices. > > Second, my enclosure is 'dual redundant'. I have two expanders > providing two paths to each drive and two SES devices in one > enclosure. In the sg interface, this becomes two handles (/dev/sg5 > and /dev/sg6 or whatever...) To handle the true multipath this > should have a single virtual handle accessing both SES devices and > failover abilities. > > However, my end customers will never need such a Linux kernel system. > The enclosure is only supported by the mfg on a LSI MegaRAID. The LSI > firmware already works perfectly with this system. It reports one SES > device and each drive one time and has no problems if one expander is > removed, re-added then the second expander removed. The LSI hides the > SES from the OS anyway, just like it hides the individual drives. > > > Does anyone have similar needs or working on something like this? I'm not aware of anyone working on this, but I'm sure it's needed by other aswell! > If I don't find anything our there, I intend on writing my own kernel > module to support this. > Would it be useful enough to share and possibly submit a patch? Yes please, definitely send a patch :) -- Pasi > RJW. > -- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
