[ltp] Re: Generic battery interface

[Michael Olbrich]

--6c2NcOVqGQ03X4Wi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Aug 01, 2006 at 01:45:27AM +0300, Shem Multinymous wrote:
>>And keeping the latest readout for each app isn't that heavy. After all
>>we already have to keep track of the timeouts for each app.
>
>The timeouts bookkeeping will normally be done by some infrastructure,
>and can often be (in principle) be optimized to less than on value per
>app. Also, it's just one timestamp. By contrast, what you're asking
>for requires explicit handling by every driver, and the attribute
>value may take significant amount of storage -- per app.

If you are that concerned about storage why the complex timeout model?
That can easily handled in userspace with just the blocking and
nonblocking reads.

> >Another way to handle this:
> >A lot of applications are interrested in changes. It would be perfectly
> >reasonable for a poll() to block for over 1 minute while the value
> >fluctuates with changes less than e.g. 1%. As soon as the change
> >(compared to the last readout) exceds this threshhold poll() returns
> >immediatelly. This could of course be combined with the proposed
> >timeouts.
>=20
> The app can do this itself by polling and checking the value, with a
> (not too) small value of dupeq.min_wait. In the case of a
> polling-based data source, the resulting hardware queries and timer
> interrupts are exactly the same as an in-kernel implementation which
> does the polling and comparions itself. If the data source is
> event-based then the comparison in userspace does have a drawback: the
> comparions are done just dupeq.min_wait apart even if the event rate
> happens to be higher. Can you think of a case where this matters?

The problem I see is the overhead. Visual feedback that feels
instantaneous would require dupeq.min_wait<50ms. And as far as I can
tell each read requires to switch from userspace to kernelspace and
back. When I look at the available variables I can easily imagine
applications that would read >10 variables. That's not something I would
want to do that often.

m


--6c2NcOVqGQ03X4Wi
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEzz5H3fK8vSqP5HsRAhX5AKC/HSVHFIWXY7/QEwTKQHiph6gdCgCggyIi
S1MKuNhj0gDX2OvjKEeFuow=
=mWLP
-----END PGP SIGNATURE-----

--6c2NcOVqGQ03X4Wi--