Hi Linus! > This driver does not block any simultaneous use of other SMART > userspace tools, it's a both/and approach, not either/or. The problem with all this is that the storage topology is largely undiscoverable for monitoring purposes. We can use heuristics, but in many cases there is no reliable way to find out that there is an ATA device behind member #3 of a USB-attached RAID controller's virtual disk #5. So while I am sympathetic to providing this type of information inside the kernel, the complexity of getting it right is mindboggling. Which is why it currently lives in smartmontools in userland. And why even the latter defers several of the topology decisions to the administrator. You could then argue that the kernel should only provide sensors for a trivial subset of configurations such as direct-attached ATA/SAS/USB devices that provide sufficient heuristics to ensure we don't accidentally send commands down that may wedge the device. I.e. repicate smartmontools' heuristics inside the kernel. That's a valid position but I remain unconvinced that it's worth it. Do you have specific user cases other than this particular RAID box without enclosure sensors? (It's also worth noting that HDD temperature sensors are notoriously unreliable). And finally, from an implementation perspective, both James and Doug pointed you to SAT and the SCSI Temperature Log Page. libata is our SAT. And thus the S.M.A.R.T. bits should be located in a libsmart library that libata and USB can use to fill out the SCSI Temperature Log Page. The hwmon-facing code would then use that log page instead of dissecting S.M.A.R.T. information directly. -- Martin K. Petersen Oracle Linux Engineering
