Displaying 3 results from an estimated 3 matches for "qx_flag_setvar".
2015 May 01
3
nutdrv_qx interface change proposal item_t::preprocess
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I would like to propose an interface change/extension, in order to be
able to clearly differ from a PRE_SEND and a POST_RECEIVE
item_t->preprocess-ing calls.
IMHO there is no option to differ from item->preprocess(..), called from
[1] and called from [2], at the moment. My idea is to extend the
item_t->preprocess(..) with an additional
2015 May 19
0
nutdrv_qx interface change proposal item_t::preprocess
...in this
case, too, I can't see the ambiguity.
- preprocess(): this function is executed
* for queries: to translate a value from device-form to NUT-form (so
direction is DEVICE -> NUT, i.e.: read from device the 'answer' to
that query);
* for instant commands/setvars (QX_FLAG_CMD/QX_FLAG_SETVAR): to fill
the command to be sent to device with data from NUT-form to
device-form (so direction is NUT -> DEVICE, i.e.: write to device;
answer is expected to be either 'command accepted' or 'command
rejected').
So direction already depends on item_t type (i.e. qxflags).
At th...
2015 May 22
1
nutdrv_qx interface change proposal item_t::preprocess
...#39;t see the ambiguity.
> - preprocess(): this function is executed
> * for queries: to translate a value from device-form to NUT-form (so
> direction is DEVICE -> NUT, i.e.: read from device the 'answer' to
> that query);
> * for instant commands/setvars (QX_FLAG_CMD/QX_FLAG_SETVAR): to fill
> the command to be sent to device with data from NUT-form to
> device-form (so direction is NUT -> DEVICE, i.e.: write to device;
> answer is expected to be either 'command accepted' or 'command
> rejected').
> So direction already depends on item_t ty...