[Nut-upsdev] Adding debugging information in serial.c

Arnaud Quette aquette.dev at gmail.com
Fri Oct 31 10:18:55 UTC 2008


Hi Arjen,

2008/10/30 Arjen de Korte <nut+devel at de-korte.org>:
> In order to improve the diagnostics for serial connected devices, I
> would like to add the possibility to differentiate between errors and
> timeouts.
>
> For the ser_get_char() and ser_get_buf_len() we might do this by
> changing the return value. For the first, return value -1 would be an
> error, 0 a timeout and 1 success. The latter could return -1 on error,
> between 0 and (buflen-1) for a timeout and buflen for success.
> Unfortunately, the ser_get_line_alert() and ser_get_line() functions
> don't have a fixed number of bytes (this is determined by the
> endchar). So we can no longer check if an endchar was received. Bad
> idea.

all these functions take parameters for the timeout (long d_sec, long d_usec).
These even all use select_read() to manage the timeout. Maybe
something to do there!
so even with the "endchar" based functions, you're still able to
differentiate between timeout and other errors.
or did I miss something?

> I'd prefer to add a couple of upsdebug statements in the serial.c
> library instead. This would leave the interface intact, at the cost of
> possibly redundant upsdebug statements (if the drivers already provide
> these). Before bailing out with -1 on error or timeout, the
> ser_get_*() functions would tell why (error with errno or mention
> timeout) at debug level 4 and show what they have received so far at
> debug level 5. Any objections?

I would prefer the former since it's cleaner.
now, if you see any show stopper, the 2nd is fine. We're not on a
critic bit of code.
though having optimized debug output is important to us.

cheers,
-- Arnaud



More information about the Nut-upsdev mailing list