linux-kernel - Re: Generic battery interface

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: <20060730142943.2537124e.khali@linux-fr.org>
Date:	Sun, 30 Jul 2006 14:29:43 +0200
From:	Jean Delvare <khali@...ux-fr.org>
To:	Pavel Machek <pavel@...e.cz>
Cc:	Greg KH <greg@...ah.com>, lm-sensors@...sensors.org,
	Shem Multinymous <multinymous@...il.com>,
	"Brown, Len" <len.brown@...el.com>,
	Matthew Garrett <mjg59@...f.ucam.org>, vojtech@...e.cz,
	kernel list <linux-kernel@...r.kernel.org>,
	linux-thinkpad@...ux-thinkpad.org, linux-acpi@...r.kernel.org
Subject: Re: Generic battery interface

Hi Pavel,

> > > We also need to decide on clear convention about units. Are they in
> > > the output and/or filename? Filename is best, I think, since it's
> > > impossible to miss and works nicely for input attributes too.
> > 
> > Actually, this whole thing could probably just go under the 'hwmon'
> > interface, as it already handles other hardware monitoring events.  I
> > don't see how a battery would be any different, do you?
> 
> Heh... yes, hwmon already has voltage, current, and more importantly,
> a maintainer.
> 
> I'd still prefer batteries to go into /sys/class/battery/... they are
> really different from lm78-style voltage sensor and I'd not expect
> battery applet to understand all the fields "normal" hwmon
> exports.

This probably doesn't matter much, every application can handle only
the subset it is interested in. For example a dockapp displaying the
system temperature only cares about the temp* files and ignores the
in*, fan*, etc. files.

However, it would be convenient if the battery monitoring application
had an easy (and non heuristic-based) way to distinguish between a
battery and a hardware monitoring chip. In that sense, having a
separate class makes sense. This doesn't prevent the battery drivers to
use the same conventions used by the hardware monitoring drivers.

> But conventions developed by hwmon group look sane and usable.

Nice to read this for a change, usually people have only complaints
about it ;)

> Actually I do not see "hwmon infrastructure" to exist. Every driver
> just uses sysfs directly. I'm not sure that the best option --
> "input-like" infrastructure can make drivers even shorter -- but
> perhaps just directly using sysfs is best for simple task like a battery?
> 
> Jean, any ideas?

I guess we never felt any need for an "infrastructure", else we would
have created it. I have no idea what the "input infrastructure" looks
like so I can't compare. If you have something to propose which would
refactor some code amongst the hardware monitoring drivers or would
otherwise makes thing better, speak up :)

Note that the hwmon class is merely a way to find out which devices
have hardware monitoring attributes. There are no class attributes in
use. The reason is historical, and also due to the fact that no two
hardware monitoring chips have the same set of features.

-- 
Jean Delvare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/