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

[Ben Hutchings <bhutchings@solarflare.com>]

On Fri, 2012-01-06 at 17:55 +0000, Waskiewicz Jr, Peter P wrote:
> > -----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.

> 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.

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.