While it's of course correct that hddtemp should be dropped before next stable freeze, it's not
correct to suggest that either lm-sensors or /sys hwmon data are direct drop in replacements.
inxi switched to defaulting to the /sys based block device temp data as soon as it became available,
before even the interfaces and paths stabilized, but on that journey, 2 things were discovered:
1. Older drives did not have /sys based hwmon temps in some or many cases. hddtemp did, suggesting
there was a legacy method of getting temps from hdds, or something, I don't know the specifics.
2. lm-sensors offered no way to map the drive sensors to the actual drives, I looked, and could find
no obvious way to do it, so inxi ended up basically starting at the block devices in /sys, then
working its way back to their hwmon data. This worked well, but took some testing to get running. I
could find no way to make that journey from sensors output to the drive however, though I assume
there is way, but it is not obvious. In other words, lm-sensors will not tell you which drive has
the temperature it lists, it will tell you that a sensor has that drive temp, which is significantly
different, and of only marginal utility in my opinion. So basically lm-sensors doesn't replace
hddtemp, and inxi worked around that issue, so that it does map the temps to the drives.
It's also worth noting that nvme from the start, despite its internal paths changing for hwmon
initially, was always available, I do not believe you needed to load a kernel module for those, and
if I recall correctly, hddtemp did not always have those temps, though I could be wrong on the
latter, it's been a while since that was implemented, I'd have to check the release notes to see.
A second point is that end users in fact have to enable the drivetemp module, they do not have to
enable the nvme temp modules, those appear to be built in. This is not particularly intuitive, so
one hopes that distributions will enable drivetemp module by default since that would be what the
majority of users I believe would want, and leave disabling it as the action to be taken for those
who did not want it enabled, which would be in general a tiny minority of users.
Note that with hddtemp, you did not have to enable anything, you just installed it, and ran it as
doas/sudo/root, and it would 'just work'. Probably had corner cases where that was not the case, of
course, like anything, but in general, if you have old hardware, you're probably better off using
hddtemp today than relying on the /sys hwmon data, at least that's what I remember finding in my
testing, but I don't really try to remember all this after the testing/development phase ends.
But sensors / hwmon are not equivalent to hddtemp. They are lovely new additions, and I for one
certainly always welcome being able to drop a dependency for a feature and use non root modes to get
data, it's faster, first of all, a lot faster, and it will always work, assuming in this case
drivetemp module has been loaded by the end user, or ideally, as default by the distro, which will
create the most seamless end user experience possible.
thanks,
Harald, inxi dev.
On Sun, 19 Dec 2021 12:53:55 +0100 Aurelien Jarno <aure...@debian.org> wrote:
Package: inxi
Version: 3.3.11-1-1
Severity: minor
Dear maintainer,
inxi recommends hddtemp which is going to be removed from the archive.
hddtemp is a software from another age that will not be shipped with
Debian Bookworm release [1]. However it could be easily replaced by the
drivetemp kernel module (available since kernel 5.6) which uses the same
hwmon interface as for NVME drives and other systems sensors and is
supported by lm-sensors. It does not require any privileged, as opposed
to hddtemp which runs as a daemon or a setuid binary.
inxi currently recommends both hddtemp and lm-sensors, offering an easy
transition. The only thing to do is therefore to drop the hddtemp
recommends. Note that recommends do not affected installability, so
there is no urgency in doing so, but it should eventually be dropped.
Regards,
Aurelien
[1] https://sources.debian.org/src/hddtemp/0.3-beta15-54/debian/NEWS/
