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

On Fri, 2012-01-06 at 18:20 +0000, Waskiewicz Jr, Peter P wrote:

quoted

-----Original Message-----
From: Ben Hutchings [mailto:bhutchings@solarflare.com]
Sent: Friday, January 06, 2012 10:09 AM
To: Waskiewicz Jr, Peter P
Cc: Michal Miroslaw; Skidmore, Donald C; Kirsher, Jeffrey T;
davem@davemloft.net; netdev@vger.kernel.org; gospo@redhat.com;
sassmann@redhat.com
Subject: RE: [net-next 8/9] ixgbe: add interface to export thermal data

On Fri, 2012-01-06 at 17:55 +0000, Waskiewicz Jr, Peter P wrote:

quoted

quoted

-----Original Message-----
From: Michał Mirosław [mailto:mirqus@gmail.com]
Sent: Thursday, January 05, 2012 3:51 PM
To: Skidmore, Donald C
Cc: Ben Hutchings; Kirsher, Jeffrey T; davem@davemloft.net;
netdev@vger.kernel.org; gospo@redhat.com; sassmann@redhat.com;
Waskiewicz Jr, Peter P
Subject: Re: [net-next 8/9] ixgbe: add interface to export thermal
data

Drivers outside of drivers/hwmon just select HWMON in Kconfig. This
adds a 3kB .c file to the kernel build for the first one that needs it.

This is where we run into issues though.  We can put this dependency
in, but customers don't pull upstream kernels, they rely on the OSV's
to distribute updates.  The customer doesn't want HWMON, and if their
kernel doesn't ship with HWMON support for ixgbe, then we're sunk.

So if !IS_ENABLED(CONFIG_HWMON), don't try to create an hwmon device,
but create the attributes anyway.

And if CONFIG_HWMON is not enabled, are we then responsible for
creating the hwmon area in sysfs to link in our attributes?  That
would make even less sense to include HWMON attributes if HWMON isn't
built in.

No, the attributes actually appear under the parent device.

quoted

quoted

The point is what we're trying to implement, based on what our customers'
requirements are, is something completely different than what HWMON is
providing.  Trying to wedge HWMON onto this framework we're trying to
provide just overcomplicates the entire thing we're trying to provide.
It's a generic interface to generic data in our drivers,

[...]

It sounds like you want to provide a "generic" ixgbe interface on different
operating systems.  But that is not a valid argument for an in-tree driver.

No, we're trying to provide a generic ixgbe interface on Linux
systems.  The reality is different OSV's pull our driver from upstream
to build their distros,

Yes we know.

[...]

The reality is these attributes of our thermal sensors are about 5% of
the data we need to export.

[...]

And I think all you need to do is (1) give these particular attributes
the right names and (2) create a child hwmon device if possible.  Is
that so hard?

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.