linux-kernel - Re: [PATCH] hwmon: Driver for SCSI/ATA temperature sensors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 16 Sep 2009 22:43:18 +0500
From:	Constantin Baranov <const@...as.ru>
To:	Julian Calaby <julian.calaby@...il.com>,
	James Bottomley <James.Bottomley@...e.de>
Cc:	Pavel Machek <pavel@....cz>, linux-kernel@...r.kernel.org,
	linux-scsi@...r.kernel.org
Subject: Re: [PATCH] hwmon: Driver for SCSI/ATA temperature sensors

On Mon, 14 Sep 2009 17:00:20 +0200 Pavel Machek <pavel@....cz> wrote:
> Well, having unified kernel<->user interface for temperature sensors
> makes sense.

This is my exact motivation.

On Tue, 15 Sep 2009 15:57:39 +1000 Julian Calaby <julian.calaby@...il.com> wrote:
> On Mon, Sep 14, 2009 at 00:00, James Bottomley <James.Bottomley@...e.de> wrote:
> > So really, given the complexity of just obtaining the data and the
> > problem of matching which data to obtain to which device you have, why
> > not just use smartctl from userspace for monitoring?  you could even
> > just plug into smartd, it seems to have most of the necessary heuristics
> > built in already.
> 
> There's even a util called hddtemp which handles all this and has a
> database of smart attributes to use for most drives.

Of course, I know about both smartctl and hddtemp tools.

On Sun, 13 Sep 2009 09:00:53 -0500 James Bottomley <James.Bottomley@...e.de> wrote:
> The basic problem are the effects.  Right at the moment it tries to send
> an ATA_16 encapsulated SMART command to every SCSI device in the system.
> We simply can't allow this.  A huge number of SCSI presenting USB
> devices are known to lock up when they see either ATA_X encapsulation or
> SMART commands.  It's not really even safe to send ATA_X to SCSI
> devices.  The modern ones should all error out fine, but the older ones
> are likely to be less tolerant.

I looked for reliable method of classifying devices. Unfortunately,
without success. Maybe it's better to disable automatic scanning and provide
a user (udev) with ability to enable monitoring on explicitly pointed device.

> Smart attribute 194 is highly vendor specific ... for instance my new
> SATA drive doesn't implement it (it does implement 190 instead).

Unfortunately, every SMART attribute is either reserved or vendor specific
as per T13. AFAIK, 194 is the most popular. That's why I have chosen it
in the first version. However, attribute number (and interpretation method
as well) may become configurable. Moreover, we can use hddtemp database
to initially configure scsitemp. And use unified hwmon interface later :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/