[Nut-upsdev] [nut-commits] svn commit r1136 - in trunk: . drivers

[Arjen de Korte]

Alexander I. Gordeev wrote:

> But I don't want to duplicate the code! I just didn't look that far in
> the future ;) (Btw, if a new subdriver appears it could need flushing in
> a copletely different way. Then it would be simpier to have several
> functions for specific _methods_ and pointers to them in the subdriver
> definition.)

There never will be another way to flush the I/O buffers, that's not how
USB works. A RS232 connected device may choose to send data at will,
which will be kept in the OS input buffer until an application reads it
or chooses to flush the buffer. Therefor, the ser_flush_io() function
may be useful for almost *all* serial drivers. USB works in a polling
mode, which means that the device can never send data without being
asked to do so. Therefor, the only buffers that may need flushing, are
the ones internal in the USB device. The only way to empty these, is to
read from them.

[...]

> P.S. Well, maybe there is a problem with our upsdebugx() semantics: we
> mix harmless messages and potentially cautionary ones. I'd better introduce
> a new one - upswarning().

We already have major problems that driver authors don't know how to use
upsdebugx() messages. Even you don't seen to know (no pun intended). A
upsdebugx() message is used to tell the developer why a program is
making a certain decision, not if something is (possibly) an error. The
level you give to it, should reflect the severity. So something that is
potentially cautionary would have a debug level of 1 or 2, while a
strictly informational message would get probably 5 or higher. By doing
so, you can easily adjust the amount of information presented.

Best regards, Arjen