From: Clark Williams <williams@redhat.com>
To: Rodolfo Giometti <giometti@linux.it>
Cc: linux-mips@linux-mips.org
Subject: Re: Battery status
Date: Fri, 22 Jul 2005 14:08:05 -0500 [thread overview]
Message-ID: <1122059285.10743.30.camel@riff> (raw)
In-Reply-To: <20050722153453.GI21044@enneenne.com>
[-- Attachment #1: Type: text/plain, Size: 1622 bytes --]
On Fri, 2005-07-22 at 17:34 +0200, Rodolfo Giometti wrote:
> > Gah. Sorry, you were asking for an answer and I turned this into a
> > design discussion. My opinion: if you're in a hurry, write a simple
>
> Nonono. It's very interesting what you are saying!
>
Ok, just remember: you asked for it! :)
> > driver that presents a /proc interface to get to battery information.
>
> Ok. Currently I have some time to spend on it... do you have any
> suggestions about I can start developing it in the good way? :)
I would start out deciding where the user-space interface would live. If
it were me, I'd probably create a /proc entry called <myplatform> (where
<myplatform> == whatever mips platform you're using, e.g. malta4kc),
then put proc entries for whatevery you're interested in in there. For
example, I'd do battery like this:
/proc/malta4kc/battery/{info,status}
So that if you cat the info entry, you'd get the make, model, capacity,
etc. If you cat the state entry, you'll get remaining charge, charging
state, discharge rate, etc. Anyway, that's good enough to start with and
if later you want to make it more generic, you can get more opinions on
where it should live in the filesystem.
Then, I'd go look at some driver modules that manage /proc entries (like
the acpi stuff). To start with I'd put a skeleton in place that
responded with fixed values, then write up some underlying routines to
actually grab stuff from the battery in response to a read from
the /proc entry.
What platform are you doing this for?
Clark
--
Clark Williams <williams@redhat.com>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2005-07-22 19:06 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-22 14:22 Battery status Rodolfo Giometti
2005-07-22 14:53 ` Clark Williams
2005-07-22 15:14 ` Rodolfo Giometti
2005-07-22 15:25 ` Clark Williams
2005-07-22 15:34 ` Rodolfo Giometti
2005-07-22 19:08 ` Clark Williams [this message]
2005-07-23 12:17 ` Rodolfo Giometti
2005-07-22 19:17 ` Ralf Baechle
2005-07-22 21:10 ` Clark Williams
2005-07-22 21:23 ` Ralf Baechle
2005-07-22 22:07 ` Clark Williams
2005-07-22 22:16 ` Ralf Baechle
2005-07-22 23:14 ` Alan Cox
2005-07-25 12:00 ` Maciej W. Rozycki
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=1122059285.10743.30.camel@riff \
--to=williams@redhat.com \
--cc=giometti@linux.it \
--cc=linux-mips@linux-mips.org \
/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