Re: [Lcd4linux-devel] Dynamic loading of drivers / plugins ?

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

Hi Xavier,

[hashes]
> I didn't wrote the XMMS plugin ! It was done by Markus Keil.

Sorry. Marksu, are you listening? Are you subscribed to lcd4linux-devel?


> So it  
>  means a function can store data within a hash, which is used by the
>   evaluator, am I right ? There should be some way to call periodicaly
>  a plugin so it refreshes the info.

The hashes have nothing to do with the evaluator.
> I wonder if this model won't be more memory and CPU using that calling
> bare functions. Maybe it would be used for "static" informations (like
> cpuinfo or uname), but I don't think it'd be used for pooling plugins,
> IMHO.

The reason for hashes is the following:

Say you write a plugin which returns values from /proc/cpuinfo. There 
are values like "CPU MHz" or "BogoMips". You get these values by reading 
and parsing /proc/cpuinfo.

Now if the plugin is asked for "MHz", it doesn't know that a few 
microseconds later a call for "BogoMips" will happen. Therefore for 
every call, the whole file would be parsed.

If you use a hash, you fill up the hash with all values from 
/proc/cpuinfo when parsing it. Subsequent calls would not parse the file 
again, but read the values from the hash.

You have to use something like a "timeout", and remember the time when 
the contents of the file was last read. If the timeout is over, you have 
to read and parse the file again.

SOme file change very seldom (/proc/cpuinfo probably changes never), 
others change quite regular. But you can save a lot of CPU if you define 
a timeout of, say, 100 msec.


> I was thinking about a compiletime-generated hash asociating plugins and
> the functions/drivers it provides, for example :

would be a possibility, too. But I'm afraid this would complicate the 
whole autotools stuff even more.

> In this way, the lcd4linux binary always know about which displays it
> can drive (and which .so to load for them) and 'lcd4linux -l' can
> esailly list the displays it support

But it doesn't know which models are supported by a particular driver. 
This info is known to the driver only. There may be drivers which 
support a lot of different models (MatrixOrbital for example), or with 
no models at all (or one Model named "any"), as the HD44780.

> For the plugins, it's a different approach : the evaluator doesn't know
> any function (except the ones defined in eval.c, and maybe plugin_math.c
> and plugin_string.c) but just a hash. If an undefined function is
> called, the eval can browse the hash for the function and if it is
> provided by a plugin, it can load it.

Hmm. I don't like this approach. The new structure will allow the use ov 
"events". Such an event can happen any time, maybe long after lcd4linux 
was started. If such an event requires a function which cannot be 
loaded, an error would occur. And you'll have no chance to test if all 
plugins and expressions are right.

> Someone may think it'll introduce a speed down, but this search is done
> only in the first loop, then it's like if nothing was changed. It may
> slowdown a bit interactive mode (but it's just intended for testing,
> isn't it ?)

Anyway, lets keep this ideas in mind, but try to get the "static" 
lcd4linux up and running first!

I made lots of progress lately. Tomorrow morning I even had my first 
marquee-like text field on my MatrixOrbital!

Stay tuned!

bye, Michael

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