netdev - RE: [net-next 8/9] ixgbe: add interface to export thermal data

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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 5 Jan 2012 22:57:04 +0000
From:	"Skidmore, Donald C" <donald.c.skidmore@...el.com>
To:	Ben Hutchings <bhutchings@...arflare.com>
CC:	Michal Miroslaw <mirqus@...il.com>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"gospo@...hat.com" <gospo@...hat.com>,
	"sassmann@...hat.com" <sassmann@...hat.com>,
	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
Subject: RE: [net-next 8/9] ixgbe: add interface to export thermal data

>-----Original Message-----
>From: Ben Hutchings [mailto:bhutchings@...arflare.com]
>Sent: Thursday, January 05, 2012 10:36 AM
>To: Skidmore, Donald C
>Cc: Michal Miroslaw; Kirsher, Jeffrey T; davem@...emloft.net;
>netdev@...r.kernel.org; gospo@...hat.com; sassmann@...hat.com;
>Waskiewicz Jr, Peter P
>Subject: RE: [net-next 8/9] ixgbe: add interface to export thermal data
>
>On Thu, 2012-01-05 at 17:53 +0000, Skidmore, Donald C wrote:
>> >-----Original Message-----
>> >From: Michał Mirosław [mailto:mirqus@...il.com]
>> >Sent: Friday, December 23, 2011 9:59 AM
>> >To: Kirsher, Jeffrey T
>> >Cc: davem@...emloft.net; Skidmore, Donald C; netdev@...r.kernel.org;
>> >gospo@...hat.com; sassmann@...hat.com; Waskiewicz Jr, Peter P
>> >Subject: Re: [net-next 8/9] ixgbe: add interface to export thermal
>data
>> >
>> >2011/12/23 Jeff Kirsher <jeffrey.t.kirsher@...el.com>:
>> >> From: Don Skidmore <donald.c.skidmore@...el.com>
>> >>
>> >> Some of our adapters have thermal data available, this patch
>exports
>> >this
>> >> data via a read-only sysfs interface.
>> >
>> >Just curious: can't this use the hwmon subsystem to be consistent
>with
>> >other system monitoring devices?
>> >
>> >Best Regards,
>> >Michał Mirosław
>>
>> Sorry about the slow response, first vacation then I hadn't heard of
>> hwmon and wanted to look into it a bit.  I can see why you mentioned
>> it as it looks to be close to what I'm trying to do here.  However I
>> don't think it quite matches.  I'll list my thoughts below:
>>
>> - We are trying to export a large set of data that our customers are
>> requesting.  The thermals were just the first patch and the other data
>> items wouldn't really fit well in the hwmon (i.e. FW version,
>> secondary MAC address).
>
>Nevertheless, there is a specific way that the thermal information
>should be exposed.
>
>> - Didn't seem like we had much data to offer hwmon anyway just sensor
>> temp, caution threshold, maxop threshold and location of sensor.  All
>> the other data (which you haven't seen yet so couldn't have known :)
>> wasn't related.
>> - The thermal data we do have is defined in our FW and could change
>> (number of sensors) based on that FW.  I wasn't sure whether that
>> would be an issue for hwmon.
>
>I have the same issue with the current Solarflare controllers, as the
>driver has no static information about specific boards.  It is possible
>to generate hwmon attributes dynamically though I've not yet got round
>to completing my implementation of this.  (Since firmware is also
>responsible for thermal shutdown, handling any of this stuff in the
>driver has been a low priority.)
>
>> - I went with sysfs based on a conversation with Peter Waskiewicz.  He
>> mentioned that there was discussion on how to export generic data at
>> netconf and sysfs was brought up as the best choice.
>
>Sensors are also exposed through sysfs, but following a specific naming
>convention and using a separate hwmon device.
>
>(Oddly, though, the sensor attributes are must be attached to the hwmon
>device's parent - which will be your PCI device.  So you may not need to
>make many changes.)
>
>Ben.
>

Hey Ben,

Thanks for all the clarifications.  I think I have a better idea what would be required from an hwmon interface. 

My one real concern with this implementation is that the ixgbe driver will now have a dependency on hwmon.  The customers that are requesting this data aren't interested in using hwmon and would most likely just grab the thermal information (which is a small portion of the data they are asking for us to export) directly from sysfs.  Originally they wanted the FW to export the data directly, when this was found to be impossible the driver became the fall back option.

I do see your point on this being a defined way to expose thermals and I want to do this the correct way.  It just seems to put a lot of overhead on the driver (dependence on hwmon) for 4 fields that the user of this data won't even be using hwmon to look at.  I guess I would feel better if we had more data to provide hwmon then its support would seem more useful.

Thanks again for bring all this up.
-Don Skidmore <donald.c.skidmore@...el.com>