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:	Fri, 6 Jan 2012 18:20:11 +0000
From:	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
To:	Ben Hutchings <bhutchings@...arflare.com>
CC:	Michal Miroslaw <mirqus@...il.com>,
	"Skidmore, Donald C" <donald.c.skidmore@...el.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>
Subject: RE: [net-next 8/9] ixgbe: add interface to export thermal data

> -----Original Message-----
> From: Ben Hutchings [mailto:bhutchings@...arflare.com]
> Sent: Friday, January 06, 2012 10:09 AM
> To: Waskiewicz Jr, Peter P
> Cc: Michal Miroslaw; Skidmore, Donald C; Kirsher, Jeffrey T;
> davem@...emloft.net; netdev@...r.kernel.org; gospo@...hat.com;
> sassmann@...hat.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:
> > > -----Original Message-----
> > > From: Michał Mirosław [mailto:mirqus@...il.com]
> > > Sent: Thursday, January 05, 2012 3:51 PM
> > > To: Skidmore, Donald C
> > > Cc: Ben Hutchings; 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
> > >
> > > 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.

> > 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, and they cherry pick patches from our drivers to achieve this.  Upstream feeds the OSV's.  Ignoring that is wrong.  We're using a common interface, sysfs, which we discussed at NetConf, and the general consensus supported these types of data to be exported by a driver.  Wrapping HWMON around this just for the sake of wrapping it around it makes no sense.  There are no plans for anyone using ixgbe to use or deploy HWMON.  So it just adds extra useless crap to our drivers and the kernel, and complicates our job of maintaining the driver by using a framework that provides no benefit to our driver or those using it.

The reality is these attributes of our thermal sensors are about 5% of the data we need to export.  The other 95% of the data, which Don stated are coming soon (still finalizing everything and testing), have nothing to do with thermal sensors.  So from a maintenance perspective, it makes it much uglier to maintain all this exported data when it's in multiple locations.  That's why we chose a contained model within the driver's sysfs space.  It doesn't affect anything else in the kernel space, and it keeps it tidy and easy to find all the data.

-PJ

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5264 bytes)