[lcdproc] Multiple devices, same driver...

[Nathan Yawn]

William W. Ferrell wrote:

> Yes. If we standardize on *one* means of conveying options to a specific
> driver, then we just parse the whole config file in one place. This
> allows flexibility in the driver (drivers can request or require
> whatever options they want, so long as they're using our format :), but
> prevents a poorly-written driver from screwing up the parsing:
> 
> [MtxOrb]
> serial_device=/dev/ttyS0
> serial_baud=19200
> serial_stop_bits=1
> serial_data_bits=8
> serial_parity=N


	Mostly good, but might I suggest something like:


[Device]
name="First Matrix Orbital Device"
driver=mtxorb.lcddriver.so
serial_device=/dev/ttyS0
serial_baud=19200
serial_stop_bits=1
serial_data_bits=8
serial_parity=N


	The [Device] identifier just indicates that what follows is info for a
new physical device (e.g. a single Matrix Orbital), it may be used as
many times as desired for as many devices as a user has.  Every time
[Device] is encountered, the LCDd/parser allocates a new data structure
for a new device.  (IMO, LCDd should always do the allocating, that'll
make it less easy to break/segfault by bad drivers.)

	The "name" is a unique identifier by which this device can be
referenced, both internally to LCDd and perhaps externally by clients as
well (remember discussions about having clients choosing one or more
from a pool of many displays?).  Name might also just be a unique
integer identifier, for the sake of simplicity.  The driver is the name
of the shared library which has code to drive this particular device. 
The rest of the data is exactly as listed earlier, because that just
makes sense.

	I have used almost this exact scheme in one of my programs, a "scorched
earth" clone.  Doing the weapons this way allows me to use the same .so
for code for several similar weapons, and it's worked very well.


Nathan Yawn
natey@hcis.net


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