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

[Arjen de Korte]

Alexander I. Gordeev wrote:

> You are right it's better to use ser_flush_io for this.
> But I still disagree on not having a special subdriver function to
> handle this. (Of course, the current ones should be renamed to, say,
> flush_<subdriver>).

Neither the agiler, nor the krauler subdrivers support flushing the
input buffers. Instead, what happens (for the agiler subdriver) is that
it will attempt to read from the device until no more data is present.
Which means that there is (should be) no specific (low level) subdriver
function to handle this.

>>> I don't know whether flushing input buffers is terribly necessary in
>>> agiler subdriver, but it's definitely not needed by krauler. And this
>>> has nothing to do with megatec driver, it is an agiler device-specific
>>> thing.
>> I know.
> So it's better to keep it inside the subdriver.

No. That's not what I said. I understand that this is a no-op for the
krauler subdriver, that doesn't mean it should be removed.

>> Don't mistake upsdebugx() messages for error messages. It is telling you
>> just that no command is set. This is *not* an error and therefor doesn't
>> need fixing. It is perfectly OK to call the get_data_krauler() function
>> without setting a command (robustness). Users will never see the output
>> from the debugging command.
> I don't agree with you.
> Yes, it certainly is not an error, it is useless but tolerated debug message.

You still don't grasp it. Just remove the debug message and you'll have
the same effect. What I certainly don't want to see in subdrivers, is
that there is code that is effectively duplicating other code. The
init() function in the agiler driver is just that. If we ever get
additional subdrivers, this means that they will have to implement this
too because you want to remove one upsdebugx() message.

> This is like arguing about compiler warnings: some people tolerate them and
> some try to eliminate them all. Well, I'm the latter one. This is just a
> point of view.

This is something completely different. Compiler warnings are messages
that are generated when syntactically there might be something wrong or
ambiguous in the code. This is not the case here.

> I think this message will make more unclearness (for everybody not in the
> context) than having subdriver-specific functions. I am even going to comment
> them :)

I think it is an utterly bad idea to try to optimize debug messages away.

Best regards, Arjen