[lcdproc] Hashes and config file. ;-) (and dynamic load)
Tue, 27 Mar 2001 13:52:37 +0100 (BST)
On Tue, 27 Mar 2001, David Glaude wrote:
> >From: Andre Breiler [mailto:email@example.com]
> >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
> >> 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.
> [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.
> 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
> 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?
> 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.
Andre' Breiler | Tel: +44 1737 839532
BBC Internet Services | Email: firstname.lastname@example.org
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