[lkml]   [2006]   [Aug]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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 <> 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

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-08-03 00:01    [W:0.035 / U:53.680 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site