[lm-sensors] Using hwmon in-kernel
tpiepho at freescale.com
Thu Oct 30 10:39:03 CET 2008
On Thu, 30 Oct 2008, Jean Delvare wrote:
>>> Because any interface that basically enforces integer->string->integer
>>> conversion is an indication that you're already doing it wrong.
> I wholeheartedly second Matthew here. Making the string-based sysfs
> interface available to the kernel would certainly be easy, but that
> would be damn inefficient. If we have to do that then let's do it right.
Does it really make that much of a difference? My guess would be that the
most significant cost of using the sysfs interface from the kernel would be
the attribute lookup and the locking sysfs does. The int/string stuff
shouldn't be much compared to that.
>> For what it used for, the sysfs int->string->int cost isn't very significant.
>> It's less than the kernel to userspace cost of sysfs.
>> If the overhead of the sysfs interface to userspace is not enough to be a
>> problem, and a kernel interface to sysfs has less overhead than from
>> userspace, then how can the kernel based overhead be too much?
> You wrote it yourself: as far as user-space is concerned, the
> int->string->int cost is less than the kernel-to-userspace cost. That's
> the very reason why the sysfs interface concept was deemed acceptable.
> For kernel-space interfaces though, there is no huge kernel-to-kernel
> cost which means that the overall cost _can_ be low. And if it can be
> low, is should be, which means: no useless int->string->int conversion.
The sysfs concept isn't acceptable for everything, only low volume interfaces
where the overhead isn't significant. You can make a faster kernel interface,
but you can make a faster userspace interface too. But some things don't need
If userspace sysfs is fast enough for a hwmon chip, why would a faster kernel
sysfs interface not be fast enough? The rate at which temperatures change,
hwmon chips update their registers, and the speed of I2C haven't changed.
> Note however that, as far as hwmon drivers are concerned, there's more
> than just the access interface to consider. Almost all hwmon drivers
> read all registers at once and cache the results for one or two
> seconds, because this made sense for the user-space users. An in-kernel
> user such as Matthew's driver would instead need to read only _one_
> sensor value, and would probably like to avoid caching it, so that his
> driver can react faster to temperature changes. So, drivers which are
> needed for in-kernel access will need to be reworked a bit anyway, we
> can't just point to the sysfs callback functions, not even if we manage
> to get them to return an integer rather than its string form.
That's a good point. I've never really liked the one second rate limiting.
It would be nice if the cache time could be adjusted at run time, or if the
user the request was made under, root/kernel vs non-root, could be taken into
>> Instead of hwmon providing this stuff, sysfs could always do it. There are a
>> lot of non-hwmon attributes that could make use of it.
> If sysfs ever offers a facility for this then yes, the hwmon subsystem
> should be converted to make use of it.
It already does offer something very much like this, see SYSDEV_ULONG_ATTR and
SYSDEV_INT_ATTR in sysdev.h and the various sysdev functions like
More information about the lm-sensors