On Tue, 31 Jul 2007 23:45:25 +0900 Tejun Heo <htejun@xxxxxxxxx> wrote: > Anyways, I don't really think this attribute belongs to SCSI sysfs > hierarchy. There currently isn't any alternative but sysfs is part of > userland visible interface and putting something into SCSI sysfs > hierarchy just because libata doesn't have one doesn't look like a good > idea. > > sysfs isn't far from being detached from kobject and driver model. I > think it would be best to wait a bit and build proper libata sysfs > hierarchy which won't have to be changed later when libata departs from > SCSI. Well, it isn't really a good way but IMHO it's better than > sticking ATA power saving node into SCSI sysfs hierarchy. "Wait a bit" could be a very long time. Who is working on building this new libata sysfs support now? If the answer is "no one", which I think it may be, do you want to hold up a feature that actually helps many people for possibly 6 months or more just because we have to go through scsi right now for our sysfs interface? on top of that, the last mail I got from James on this subject indicated that if we kept our granularity large with the power savings levels, SCSI can actually take advantage of this as well. Sure, we may have to tweak things around later, but isn't this what we do routinely? Holding up valuable features from the kernel because things aren't perfect yet seems really broken. As far as your complaints about broken hardware go, keep in mind that the patch set does provide a method of adding these disks to a blacklist, so I don't see that as a problem. And, the default for this feature is "off", and user space would have to explicitly enable it. - 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
