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