Hi,
On 7/28/06, Vojtech Pavlik <[email protected]> wrote:
> Battery polling is already used extensively, and its overhead is
> completely negligible.
You're joking, right? On quite a number of laptops, it takes quite a
while to read the battery, spent in BIOS through SMI, polling the I2C
bus while talking to the battery. The less often this is done, the
better.
Yes, I know -- tp_smapi does that too. And it's still negligible,
usually a few microseconds.
Heck, the hdaps driver polls that same I2C bus 50 times per seconds
and still doesn't tickle the load average.
> I'm yet to see any deployed userspace code
> trying to query battery status more than once per second.
The applets that were doing it (yes, up to 100 times per second)
corrected their ways pretty quickly, because some machines became
unusable with the applet enabled.
Exactly -- and they've been working merrily ever since.
And if you don't want to trust applet developers, cache the latest
reads and refresh them only if X jiffies have passed.
You could, trivially, mirror the behavior of current applets: Not report
the changes to the battery status more often than each N seconds, except
for critical events.
You're taking a polling-based hardware, exposing it as an event-based
interface, and then and kludging it so that it behaves like polling
again...
So, in this scheme, how many lines of code does is the equivalent of
"cat /sys/devices/platform/smapi/BAT0/voltage"?
> And you'll need to identify devices in a useful way, a problem that's
> not yet solved even for input devices... You see where it's going.
May you be more specific here? I'm not aware of any problems in this
area. This may be my fault: What needs to be fixed there?
"Generic interface for accelerometers (AMS, HDAPS, ...)" on LKML, a
few weeks ago, about moving accelerator-based hard disk parking from
sysfs polling to the the input infrastructure. One unresolved issue
was how to find which input device happens to be the relevant
accelerometer.
Shem
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
