Linus, > That should be last resort, what the SCSI people want is noble, > and they did a tremendous (impressive) work by hiding all the ATA drives > behind SCSI emulation with libata, so they want me to keep up > that tradition by also making the temperature reading behave > "as if it was a SCSI drive" too so I'm on board with trying that out > even if I think the bar is a bit high for causal contributors. I definitely don't expect you to do all the work for every type of device known to man. And I'm happy to help. But obviously the overall approach needs to work for everything we can realistically support so it becomes a generally useful interface and not something ad-hoc for a small subset of configurations. But more importantly: I need to make sure that no device is harmed in the process of extracting temperature sensor data. My highest priority is not breaking people's storage or causing data loss. So I have to balance the benefits of your temperature stuff vs. all the devices we risk messing up by sending commands we haven't attempted before. We have lots of battle scars from devices that not only implement the specs poorly, but can lock up completely when sent a command they didn't expect. So there is quite a bit of risk involved. It's not just a matter of devices politely declining the request. Often even a reset isn't enough and the user will have to unplug/power cycle the device to bring it back. No fun. So as usual it's dealing with the failure scenarios that's the hard part, not making the feature work for things that implement the protocol correctly. And that's why I'm asking all these questions. The userland tooling is entirely admin-configurable whereas inside the kernel we have to resort to guesswork and heuristics during device discovery. That's always a tricky game to play. Hope that makes sense? -- Martin K. Petersen Oracle Linux Engineering
