[Top] [All Lists]

Re: Battery status

To: Rodolfo Giometti <>
Subject: Re: Battery status
From: Clark Williams <>
Date: Fri, 22 Jul 2005 14:08:05 -0500
In-reply-to: <>
Original-recipient: rfc822;
References: <> <1122044036.10743.5.camel@riff> <> <1122045924.10743.16.camel@riff> <>
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:


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 Williams <>

Attachment: signature.asc
Description: This is a digitally signed message part

<Prev in Thread] Current Thread [Next in Thread>