--- On Tue, 2/5/08, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> 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 ^^^^^^^^^^^ See last paragraph. > 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 ... The vendor would've abstracted that away most commonly using SES. > > > 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. You missed my point. Your abstraction is redundant and arbitrary -- it is not based on any known, in-practice, usage model, already in place that needs a better, common way of doing XYZ, and therefore needs an abstraction. Luben - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
