Hello all. 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? 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? 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
