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]
Message-ID: <1340659554.2572.52.camel@bwh-desktop.uk.solarflarecom.com>
Date:	Mon, 25 Jun 2012 22:25:54 +0100
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	Michael Chan <mchan@...adcom.com>
CC:	David Miller <davem@...emloft.net>, <netdev@...r.kernel.org>,
	<nsujir@...adcom.com>, <mcarlson@...adcom.com>
Subject: Re: [PATCH 3/3 net-next] tg3: Add sysfs file to export sensor data

On Mon, 2012-06-25 at 14:04 -0700, Michael Chan wrote:
> On Sat, 2012-06-23 at 16:02 +0100, Ben Hutchings wrote: 
> > Temperature and voltage can be exposed through an hwmon device (which
> > practically means you use multiple attributes with conventional names).
> > Other diagnostics might possible be suitable for ethtool stats,
> > depending on what they are.
> 
> I think we can extract some common and more useful attributes such as
> temperature and voltage, and use the standard hwmon attributes to expose
> them.
> 
> > 
> > If the driver can't easily parse the information (e.g. it varies greatly
> > between the different chips and firmware versions) then a binary
> > attribute or private ioctl might be appropriate.  But generic interfaces
> > really should be considered first.
> > 
> 
> The rest of the bulk data requires too much parsing in the kernel and
> will have to be exposed as binary data.  What do you mean by binary
> attribute?  A new binary sysfs attribute under hwmon?  Or outside of
> hwmon?

A binary sysfs attribute under your PCI device.  (In fact, for wider
userland compatibility, hwmon sysfs attributes should also be under the
PCI device rather than the hwmon device.  Yes, this *is* a weird
convention.)

> And please elaborate on the private ioctl.

Every driver gets to handle SIOCDEVPRIVATE .. SIOCDEVPRIVATE+15.  But
avoid the first 3, as userland may blindly try to use them for MDIO.
David may of course tell you that you should under no circumstances
actually do this.

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.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ