search for: qx_flag_setvar

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...