Nut upsdev - Jan 2008 - passing nut_debug_level from upsdrvctl to drivers

Is there any reason why we couldn't pass the -D flags (counted by
nut_debug_level) from upsdrvctl to the individual drivers? It seems a
little strange to suggest to users that they should start the drivers
with upsdrvctl normally, but then start them by hand for debugging.
(If we want to debug upsdrvctl itself, we could use another flag for
that, instead of -D.)

-- 
- Charles Lepple

> Is there any reason why we couldn't pass the -D flags (counted by
> nut_debug_level) from upsdrvctl to the individual drivers? It seems a
> little strange to suggest to users that they should start the drivers
> with upsdrvctl normally, but then start them by hand for debugging.
> (If we want to debug upsdrvctl itself, we could use another flag for
> that, instead of -D.)
You're not the first to ask:

http://lists.alioth.debian.org/pipermail/nut-upsuser/2007-May/002712.html

I don't think this is a good idea. Passing a driver the -D option, will
prevent it from backgrounding. When more than one driver is started by
'upsdrvctl' (you'd never know without looking at
'ups.conf'), it would
result in an endless mess on the console. Therefor, we want to be sure
that explicitly only one driver is started (and that we don't see
interference from other drivers).

I also think we should not encourage people to post debug output before
consultation with a developer. Most of the time, providing useful debug
output requires more than just running the driver with an arbitrary number
of -D flags anyway.

Best regards, Arjen
-- 
Eindhoven - The Netherlands
Key fingerprint - 66 4E 03 2C 9D B5 CB 9B  7A FE 7E C1 EE 88 BC 57