[lcdproc] Hashes and config file. ;-) (and dynamic load)
William W. Ferrell
Tue, 27 Mar 2001 10:02:29 -0700
Content-Type: text/plain; charset=us-ascii
--- email@example.com's mailer spewed these beefy chunks ---
> >From: Andre Breiler [mailto:firstname.lastname@example.org]
> >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=3Dyyy\n[driver]\n...)
> Ok, I feel it, you don't like long command line. ;-)
> Obviously if LCDd is run at startup we want a short command line
> and yet another config file in /etc(?).
I agree and disagree here. The command line should flexible enough to
allow someone to at least get a basic LCDd started with no configuration
file. Naturally there's gonna be so many options around that users will
*have* to use the config file to get advanced things working, but
there's nothing wrong with supporting stuff like:
LCDd --blink-backlight=3Dno --driver=3Dmtxorb
=2E..and make LCDd just assume defaults for things. Might not be
incredibly feasible, but I'd like to try.
Also, does anybody mind making driver names case-insensitive? We had a
few newbie questions awhile back about "mtxorb not working", turned out
LCDd wanted "MtxOrb", not "mtxorb". *shrug*
> >> 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 =3D 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. ;-)
That's true; I do agree that it should be available at all times.
> >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,
> now you tell me we need it again for config file... ;-)
I kinda always thought we were using hashes for both :) I'm certainly in
favor of it.
> [Side note, for protocol we can build a perfect hash function...
> 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.]
Hashes are still probably the most effective solution, so how do we
implement the imperfect hashin you suggest?
If I recall correctly, an imperfect hash is one that doesn't always hit
on the first seek into the structure. Is that right?
> Is the config file suppose to be read only at startup,
> or re-read later (for dynamic loading) when we get a signal (or ?)?
In a perfect world, yes. For our first release, this is *way* down there
at the bottom of the list of desired features :)
> 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?
Yes. I think we could eventually make it smart enough to only reinit
drivers that actually got changed, and tell clients only when necessary
that they need to set their stuff up again.
> How do we detect changes, how do we tell the driver?
To detect a change to a config file, a few things need to be done first:
* When LCDd starts up and reads the config file, it should also stat the=20
file and note its modification date.
* When LCDd is finished reading the config, it should *close* the file.
Then, every few seconds (every sixty seconds? or configurable :), if the
modification date has changed, reload. If sent a SIGHUP, always reload
(users are abusive :)
> What do we do with current client?
This depends :)
If only server-side options have changed, I don't think the clients
would even notice. Server options would include heartbeat config,
screen-on-display duration (how long a screen is shown), updates per
If something else changes, like which key is reserved for the menu, and
a client's already reserved that menu, we may be stuck just telling the
clients "server restarted; all your stuff is hosed, so start over."
That's the cleanest, although not necessarily the most elegant,
solution, but I don't think it's practical to require clients to be able
to dynamically reconfigure themselves.
William W. Ferrell, Senior System Administrator, Global Crossing Ltd.
950 17th St Ste 2200, Denver, CO 80202 1.303.223.0564
Public key available:
gpg --keyserver certserver.pgp.com --recv-key 7478FC7A
If at first you don't succeed, you are running about average.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----
Content-Type: text/plain; charset=
To unsubscribe from this list send a blank message to