Re: [PATCH v7] scsi: Add hwmon support for SMART temperature sensors
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
Re: [PATCH v7] scsi: Add hwmon support for SMART temperature sensors
On 11/23/18 12:18 AM, Linus Walleij wrote: On Thu, Nov 22, 2018 at 9:00 PM Guenter Roeck wrote: Can you possibly extract this as pure hwmon driver outside scsi control ? I'll be happy to accept it as standalone hwmon driver. 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. No problem, your call. I would just very much dislike your work to get lost, that is all. Thanks, Guenter
Re: [PATCH v7] scsi: Add hwmon support for SMART temperature sensors
On Thu, Nov 22, 2018 at 9:00 PM Guenter Roeck wrote: > Can you possibly extract this as pure hwmon driver outside scsi control ? > I'll be happy to accept it as standalone hwmon driver. 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. Yours, Linus Walleij
Re: [PATCH v7] scsi: Add hwmon support for SMART temperature sensors
[-cc] Hi Linus, On 11/22/18 5:49 AM, Linus Walleij wrote: [ ... ] (It's also worth noting that HDD temperature sensors are notoriously unreliable). I am sorry if you think that D-Link does bad engineering, what I am trying to achieve is upstream support for this device, without any out-of-tree patches. The D-Link DIR-685 uses the harddisk sensor for this, whether we like it or not. Following the above argument (not yours, the one about accuracy), I guess we should drop support for all CPU temperature sensors from the Linux kernel. After all, they are known to be much more inaccurate than a HDD temperature sensor could ever be. Seriously, any argument about (lack of) sensor accuracy should be silently ignored. I may be overly pessimistic nowadays, but whenever I see such an argument, I read it as "we'll never accept your patch, so better stop wasting your time and forget about it". I hope I am wrong, but it seems to me that this is where things are going. Can you possibly extract this as pure hwmon driver outside scsi control ? I'll be happy to accept it as standalone hwmon driver. Thanks, Guenter
