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

[Xavier V. <xav...@fr...>]

> btw, I just added some "hash" utility functions, they work similar to 
> the 'associative arrays' from perl. You can use them to store 
> information gathered from various /proc files (I'm pointing at your xmms 
> plugin). Take a look at plugin_cpuinfo.c, which parses /proc/cpuinfo, 
> and you get an idea of how this could be done.

I didn't wrote the XMMS plugin ! It was done by Markus Keil. 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.
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.


> As I'm not familiar with dlopen() and friends, maybe someone out there 
> wants to take a look at that?
Sorry, I won't be very much help for this point :/

> That's right. But what about 'lcd4linux -l', which should list all 
> drivers and models? :-(
> With plugins, I could think of loading all plugins which can be found in 
> a directory, becausae they follow the naming scheme "plugin_*.so". The 
> same technique could probably be used for the "list all drivers problem"

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

drivers {
"MatrixOrbital.so" -> "MatrixOrbital"
"xyz.so" -> "displayxyz"
}

and

plugins {
"i2c_sensors.so" -> "i2c_sensors()"
"math.so" -> "sqrt, exp, ln, log, sin, cos, tan, min, max"
...
}

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

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.
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 ?)

-- 
Xavier VELLO <xav...@fr...>

PS: I'm on the lcd4linux-devel ML, so please Michael reply directly to
the ML (my GSM dislikes double posts ;)

PS #2: For the hashes, it's in Perl syntax, I don't know how hashes work in C ;)

PS #3: We may use this tree model :
/usr/lib/lcd4linux/---model/---matrixorbital.so                    
|        \-cwlinuz.so                     |                    
\-plugin/---math.so                               \-i2c_sensors.so and
forget the drv_ and plugin_ prefix for .so, moreover, CAPITALS are
deprecated, so it would be matrixorbital.so and NOT MatrixOrbital.so