From: Jean Delvare <khali@linux-fr.org>
To: Pavel Machek <pavel@suse.cz>
Cc: Greg KH <greg@kroah.com>,
lm-sensors@lm-sensors.org,
Shem Multinymous <multinymous@gmail.com>,
"Brown, Len" <len.brown@intel.com>,
Matthew Garrett <mjg59@srcf.ucam.org>,
vojtech@suse.cz, kernel list <linux-kernel@vger.kernel.org>,
linux-thinkpad@linux-thinkpad.org, linux-acpi@vger.kernel.org
Subject: Re: Generic battery interface
Date: Sun, 30 Jul 2006 14:29:43 +0200 [thread overview]
Message-ID: <20060730142943.2537124e.khali@linux-fr.org> (raw)
In-Reply-To: <20060727232426.GI3797@elf.ucw.cz>
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
next prev parent reply other threads:[~2006-07-30 12:29 UTC|newest]
Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-27 20:06 Generic battery interface Brown, Len
2006-07-27 20:32 ` Shem Multinymous
2006-07-27 23:24 ` Vojtech Pavlik
2006-07-28 0:27 ` Shem Multinymous
2006-07-28 0:36 ` Matthew Garrett
2006-07-28 7:42 ` Vojtech Pavlik
2006-07-28 12:25 ` Pavel Machek
2006-07-28 13:43 ` Vojtech Pavlik
2006-07-28 15:38 ` Shem Multinymous
2006-07-28 15:57 ` Valdis.Kletnieks
2006-07-28 22:10 ` Shem Multinymous
2006-07-28 23:14 ` Valdis.Kletnieks
2006-07-29 9:48 ` Shem Multinymous
2006-07-29 10:17 ` Vojtech Pavlik
2006-07-29 10:30 ` Shem Multinymous
2006-07-29 10:37 ` Mark Underwood
2006-07-29 11:35 ` Shem Multinymous
2006-07-30 8:35 ` Valdis.Kletnieks
2006-07-30 11:44 ` Vojtech Pavlik
2006-07-30 11:48 ` Shem Multinymous
2006-07-31 0:58 ` Valdis.Kletnieks
2006-07-31 1:34 ` Shem Multinymous
2006-07-30 9:18 ` Pavel Machek
2006-07-30 10:14 ` Shem Multinymous
2006-07-30 11:33 ` Shem Multinymous
2006-07-28 12:25 ` Dmitry Torokhov
2006-07-28 13:44 ` Vojtech Pavlik
2006-07-28 15:19 ` Shem Multinymous
2006-07-28 16:10 ` Dmitry Torokhov
2006-07-30 8:55 ` Greg KH
2006-07-30 9:52 ` Shem Multinymous
2006-07-30 11:47 ` Vojtech Pavlik
2006-07-30 12:50 ` Shem Multinymous
2006-07-30 14:29 ` Tomasz Torcz
2006-07-30 14:48 ` Shem Multinymous
2006-07-30 11:46 ` Vojtech Pavlik
2006-07-28 15:14 ` Shem Multinymous
2006-07-28 20:23 ` Vojtech Pavlik
2006-07-28 22:48 ` Shem Multinymous
2006-07-28 23:17 ` Pavel Machek
2006-07-29 10:36 ` Vojtech Pavlik
2006-07-29 11:32 ` Shem Multinymous
2006-07-29 12:04 ` Vojtech Pavlik
2006-07-29 12:51 ` Shem Multinymous
2006-07-29 13:42 ` Vojtech Pavlik
2006-07-30 9:00 ` Greg KH
2006-07-29 21:06 ` Shem Multinymous
2006-07-30 10:05 ` Pavel Machek
2006-07-30 10:34 ` Shem Multinymous
2006-07-30 10:37 ` Pavel Machek
2006-07-30 18:37 ` Shem Multinymous
[not found] ` <20060731113735.GA22081@creature.apm.etc.tu-bs.de>
2006-07-31 15:18 ` [ltp] " Shem Multinymous
[not found] ` <20060731183719.GB22081@creature.apm.etc.tu-bs.de>
2006-07-31 22:45 ` Shem Multinymous
[not found] ` <20060801114303.GA13000@creature.apm.etc.tu-bs.de>
2006-08-02 21:59 ` Shem Multinymous
2006-07-31 21:35 ` Jean Delvare
2006-07-31 22:34 ` Shem Multinymous
2006-07-31 23:01 ` Pavel Machek
2006-08-02 7:18 ` Jean Delvare
2006-08-02 7:46 ` Marek Wawrzyczny
2006-08-03 11:29 ` Thomas Renninger
2006-08-03 16:33 ` Pavel Machek
2006-07-27 22:16 ` Pavel Machek
2006-07-27 22:56 ` Shem Multinymous
2006-07-27 23:08 ` Greg KH
2006-07-27 23:24 ` Pavel Machek
2006-07-30 12:29 ` Jean Delvare [this message]
2006-08-02 19:51 ` Pavel Machek
2006-08-03 9:20 ` Jean Delvare
2006-07-27 22:56 ` Greg KH
2006-07-27 23:31 ` Vojtech Pavlik
2006-07-28 0:35 ` Shem Multinymous
2006-07-28 10:11 ` Vojtech Pavlik
-- strict thread matches above, loose matches on Subject: below --
2006-07-28 4:05 Brown, Len
2006-07-28 8:22 ` Johan Vromans
2006-07-28 9:58 ` Matthew Garrett
2006-07-28 10:10 ` Vojtech Pavlik
2006-07-28 12:21 ` Pavel Machek
2006-07-28 14:13 ` Shem Multinymous
2006-07-27 23:20 Brown, Len
2006-07-28 0:10 ` Shem Multinymous
2006-07-27 15:40 Brown, Len
2006-07-27 16:23 ` Shem Multinymous
2006-07-27 16:50 ` Daniel Barkalow
2006-07-27 20:07 ` Shem Multinymous
2006-07-27 0:20 Pavel Machek
2006-07-27 14:05 ` Matthew Garrett
2006-07-27 14:39 ` Shem Multinymous
2006-07-27 14:44 ` Matthew Garrett
2006-07-27 22:42 ` Greg KH
2006-07-27 14:59 ` Pavel Machek
2006-07-27 15:10 ` Shem Multinymous
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060730142943.2537124e.khali@linux-fr.org \
--to=khali@linux-fr.org \
--cc=greg@kroah.com \
--cc=len.brown@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-thinkpad@linux-thinkpad.org \
--cc=lm-sensors@lm-sensors.org \
--cc=mjg59@srcf.ucam.org \
--cc=multinymous@gmail.com \
--cc=pavel@suse.cz \
--cc=vojtech@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox