linux-kernel - Re: [ltp] 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <41840b750608021458h2c7238d6xe1d412cfae1d5569@mail.gmail.com>
Date:	Thu, 3 Aug 2006 00:59:00 +0300
From:	"Shem Multinymous" <multinymous@...il.com>
To:	"Michael Olbrich" <michael.olbrich@....net>
Cc:	linux-thinkpad@...ux-thinkpad.org,
	LKML <linux-kernel@...r.kernel.org>, linux-acpi@...r.kernel.org,
	"Vojtech Pavlik" <vojtech@...e.cz>
Subject: Re: [ltp] Re: Generic battery interface

Hi Micael,

I ask again: please do a Reply to All. This discussion is CCed on
several mailing lists, not just link-thinkpad.

On 8/1/06, Michael Olbrich <michael.olbrich@....net> wrote:
> 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.

Please explain how this can be done  in a way that (a) works
transparently with both event-driven and query-based drivers, (b)
handles multiple clients efficiently, (c) minimizes hardware queries
in the case of query-based drivers, and (d) doesn't cause unnecessary
timer interrupts on tickless kernels.


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

This is relevant only to query-based drivers, not event-based. How
expensive is a context switch compared to a typical hwmon hardware
query?

  Shem
-
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/