Re: [Lcd4linux-devel] i2c_sensors and hashes

[Michael R. <re...@eu...>]

Xavier,

> I'm thinking about using or not the new hash uility for my i2c_sensors
> plugin. But this plugins is bit different for the others (xmms, cpuinfo,
> ...). In fact, each value is stored in a separate file, that's the
> claim.
Right. Hmm....

> - If I use and hash to store all values it'll force to parse about a
> dozen of files for one or two used values ! I don't think it's the
> better way :/
Rivht.

> - On the other hand, using timers would be great ! Should I use a dozen
> of different timeouts ?
Hmm...

> - Have an hash for the dozen of values, which may contain "null" values
> of never asked for.
Hmmm. Or does not even contain a value for a item never asked for.

> - Have a second hash containing the timers for each value.
double-Hmmm....

> The problem with this desing may be that the overload generated by the
> hashes and all the timers may be more CPU intersive that parsing one
> file o demand.
Maybe right, but think of a scenario where oen specific value is needed 
several times: You want the temperature diplayed as a number, as a bar, 
and you want to control three different fans with it. The filke would be 
parsed five times...

> What's your opinion about this ?
My opinion is a loud and clear "Hmm..." :-)

> Michael, is it possible to use the hash to store timer values ?
Not really at the moment. A hash stores string values only.

> Is there
> another way, using only one timer ?
I'm afriad one timer isn't possible. You don't know which data source 
the timer is for.

With the new layout, each widget can have its own "polling frequency". 
Its possible to read the temparature three times a second, but some 
voltage only once a second. So there have to be different timeouts for 
different sources.

Today I implemented something new on hashes: I call it "filters". It has 
something to do with timings, but on a completely different way than 
you'd need it. This filters are for sources which require something like 
"delta processing" (e.g. /proc/stat and the "CPU busy" thing: The value 
you can read there is the absolute number of cycles the CPU spent in 
different modes. One has to calculate deltas over a specific time to get 
a "current load".

But that doesn't help you.

Hmmm....


bye, Michael

-- 
Michael Reinelt                                   Tel: +43 676 3079941
Geisslergasse 4                                   Fax: +43 316  692343
A-8045 Graz, Austria                          e-mail: re...@eu...