ACPI/PMU procfs HAL test program. Version 002.

[Sjoerd Simons]

On Mon, Jan 24, 2005 at 02:42:15PM +0000, Richard Hughes wrote:
> Danny Kukawka <danny.kukawka <at> web.de> writes:
> > > Polling is generally bad, but I don't think we have any other choices, 
> > > we? acpid(?)
> > 
> > There are two ways to get actually informations about battery states:
> > 1.) wait for ACPI Battery Event 
> > Problem: 
> > 	- not supported by all machines, and no info if or if not
> > 	- you can't say when a event is sent by the BIOS (maybe every 
> > 	  percent +/-, maybe other interval --> unknown)
> 
> ACPI events are not great from the quick look that I've given them, although
> they are good as they remove the polling for some events. Maybe a place for 
> them somewhere for some objects.
>  
> > 2.) poll /proc/acpi/battery/BAT0/state 
> > Problem:
> > 	- systemload if you poll too often.
> 
> It it measurable? Is it a problem from a power consumption or 
> proccessor load PoV?
> 
> I agree polling a battery every second for it's design capacity rating is a 
> bad idea (only needs to be done at coldplug) but wouldn't the procfs entries 
> be cached into RAM and thus lightning quick?

Note that procfs entries aren't cached into ram. When your read out a procfile
a kernel functions gets called that creates the strings for you. Now most of
these things just convert some values they have in some structs to string,
which is lightning fast.. But it's also possible that it actually does somewhat
more, for example request some data from hardware. Which can be potentially
slow/power consuming. 

And ofcourse note that i have no clue how it's implemented in acpi, so it could
both situations :)

  Sjoerd
-- 
An age is called Dark not because the light fails to shine, but because
people refuse to see it.
		-- James Michener, "Space"
_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal