[smartmontools-support] [PATCH] RFC: libata: Add hwmon support for SMART temperature sensors

[Tejun Heo]

(cc'ing Hans)

On Fri, Aug 10, 2018 at 11:53:35AM +0200, Linus Walleij wrote:
> On Fri, Aug 10, 2018 at 6:15 AM Guenter Roeck <linux at roeck-us.net> wrote:
> > On 08/09/2018 03:24 PM, Linus Walleij wrote:
> 
> > > This is a first attempt at providing a kernel-internal
> > > hwmon sensor for ATA drives. It is possible to do the
> > > same for SCSI, NVME etc, but their protocols and
> > > peculiarities seem to require a per-subsystem implementation.
> > > They would all end up in the same namespace using the
> > > SCSI name such as "sd_0:0:0:0".
> > >
> > If the implementation for other drive types needs to be different,
> > how about "ata" as prefix ?
> 
> I was thinking that since through libata all devices on ATA
> are registered to the SCSI namespace, userspace would just
> see sd_N:N:N:N and know "it is some harddrive" and we
> do not need to know if it is SCSI or ATA. This seems to be
> the way the block developers are thinking about it: ATA drives
> are entirely hidden behind SCSI, as are USB mass storage
> drives.

Yeah, I think that's the right approach given that most of libata's
interface is scsi based.

> Yeah I know you are minimalist when it comes to dmesg ;)
> 
> Let's hear what the ATA people think though, it could be kind of useful
> if someone posts a log asking what's wrong with their drive
> and it says the hard disk is 60 degrees on boot. "Man, I think you
> need to look at your fans."

I don't really mind either way as long as it's dbg but yeah hwmon core
likely is a better place to make that call.

So, one thought I have is that this doesn't really add any new
capabilities.  The information is fully discoverable from userspace
and interpreting the data requires quite a bit of heuristics.  So, do
we really need this in the kernel?

Thanks.

-- 
tejun