[lcdproc] Hashes and config file. ;-) (and dynamic load)

[Andre Breiler]

On Tue, 27 Mar 2001, David Glaude wrote:

> >From: Andre Breiler [mailto:andreb@rd.bbc.co.uk]
> >On Mon, 26 Mar 2001, Joris Robijn wrote:
> >> > > Maybe we could have a (argv,argc) kind of argument (list of string).
> >> This way we can use the same format for command line, config file and 
> >> widget language. Cool.
> >Yes sure. When you define a EOL char than you can put the complete config
> >file on the command line :) (LCDd -c 'globaloption1=yyy\n[driver]\n...)
> 
> Ok, I feel it, you don't like long command line. ;-)

Yes, write a w3 server on the cmd line of tcl :)

> Obviously if LCDd is run at startup we want a short command line
> and yet another config file in /etc(?).

I agree. Maybe I'm able to specify a config file an overwrite only same
parts ?

> >> Or read and store the values, and let the drivers request them by key. 
> >> Better encapsulation. The example that I used a short while back was:
> >> 
> >> value = get_parameter_int( "key", defaultvalue );
> >
> >Nice. Should this only available while the config is read or over the
> >complete lifetime of the server ?
> 
> I guess over the complete lifetime of the driver,
> but most driver will only read this at init time. ;-)

Yes and if we define it's only available while driver_init() is
called then we can free the memory.
With the dristributed driver in mind this should be enforced.

> >In the latter case we should use a hash to store config in the LCDd.
>  
> I have been suggestion hash for that,
> then someone said we only need it the protocol,

Yep, thats me. But the conditions have changed ?

> now you tell me we need it again for config file... ;-)

If a driver uses this often then it should be definitly a hash.
Otherwise not.
 
> [Side note, for protocol we can build a perfect hash function...

Yes this is quite easy :)

> but for the config file, we might not know the keywords used
> by each driver. So an unperfect hashing with a more dynamic
> table need to be used. However remember that hash table are
> most of the time of fixed size, this introduce limitation
> and/or waste of memory.]

Yes and you pay also cpu to build the hash.
 
> TROUBLE:
> Is the config file suppose to be read only at startup,
> or re-read later (for dynamic loading) when we get a signal (or ?)?

I think reread later would a "nice to have" thing but should be in mind on
initial design.

> If it has to be re-read and that some config of some LCD is change
> (baud rate? size? ...) should we reset and reinitialise the driver?

Definitively yes.

> How do we detect changes, how do we tell the driver?

I think you mean changes in options ?
I would reada the config reinit all things (call driver_init() again).
Every part of the system should then decide for itself what to do.
If something is removed (e.g. driver) it should be killed.
So I would do the following steps:
 - disable/ignore all non init related communication (tell this all
   connected parts ?)
 - read & parse the config (struct config allocated)
 - find removed components (e.g. a driver doesn't appear anymore)
 - remove these components (e.g. unload lib)
 - alloc and init struct LCDd status (take all things over from old
   status to new)
 - init all subsystems (e.g. call driver_init with the new LCDd status)
 - check which clients are affected (e.g. key changes, display removed)
   based on old/new LCDd status
 - notify these clients
 - set new status as working status
 - free old sttus
 - enable all communication (notify all parts of this ?)

> What do we do with current client?

The client should get a reset and should reinit itself.

Bye Andre'
-- 
Andre' Breiler                       |   Tel: +44 1737 839532
BBC Internet Services                | Email: andre.breiler@rd.bbc.co.uk 
Kingswood Warren,Tadworth,Surrey,UK  |   URL: http://support.bbc.co.uk/
Mail me.  Don't phone if possible. And use a Subject line.



-----------------------------------------------------------
To unsubscribe from this list send a blank message to
lcdproc-unsubscribe@lists.omnipotent.net