LCDproc development and user support list

Text archives Help


[lcdproc] Current developpement question...


Chronological Thread 
  • From: madmatt AT bits.bris.ac.uk (Matt)
  • Subject: [lcdproc] Current developpement question...
  • Date: Thu, 14 Sep 2000 16:01:16 +0100 (BST)

David Glaude wrote:

| Are you talking about creating a loadable library for each driver and to
| load the library that are needed only when they are needed? It sound's good
| but might turn into a nightmare.

Yes, and no.

| Well there is the issue of what kind of error message will popup if the
| library is not where it is suppose to be...

As long as the directory where the drivers are stored is entered into
/etc/ld.so.conf, the LCDd will find them. (If the drivers are bunged into
/usr/local/lib, that entry should already be there, but that's a bit
messy, much better to stick them in /usr/local/lib/lcdproc)

| But there is also the issue of portability of the code.
| Of course Windows is having DLL that would do the trick.
| And more likely other *nix have their own stuff, but how to keep it
| portable.

I'm looking into using libtool which provides portable methods for
handling shared libs on most *nix platforms. AFAIK Linux, BSD and Solaris
all support shared libs via dlopen directly...

In response to the BSD people getting annoyed, I'm trying to tag all the
Linux-specifc code with "#if defined(LINUX)" tags so it should be easy to
add the BSD support where appropriate, (and other *nices for that
matter!).

| Maybe we could support dynamic reconfiguration of LCDd (if the new screen is
| already compiled in).
| Just modify the configuration file and send a KILL xxx to the tell LCDd to
| parse again.

In some cases, it's necessary to down the entire machine to attach a
display, (in the case of the hd44780's), but as long as that isn't a
problem you could change the conf file, and SIGHUP the server to re-read
the file.

The only problem is the clients that are connected wouldn't know about the
new display, only future connected clients. Also what happens if you
delete a display that is being used? I detect a messy kludge on the
horizon...

| * About yacc/bison & lex/flex I also believe that for simple task, making
| your own parser is a lot better. I have been using yacc and lex both
| recently and long ago. They provide a good job but you also take with you a
| (two) full state machine with a lot of various feature that we absolutely
| don't need where a few lines of code could do the trick.
| I don't know wich way you wanna go, but except if you want to take that
| opportunity to learn those tools (always a bit risky) I see no point in
| using them.

Funny, the flex/yacc book states the exact opposite...

Anyway, all the parser code will be hidden behind a nice interface so that
it can be changed without breaking the rest of the server code. As long as
the functions return hashes of the options from the file in the same
format, it won't really matter...

| * Could you repeat where all those new developpent take place... Where is
| the CVS... a few pointer maybe.

Um, pass on that one... :)

Matt



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




Archive powered by MHonArc 2.6.18.

Top of page