Difference between revisions of "Sweetcomb/Sysrepo"
From fd.io
m (→Sysrepo) |
m (→Sysrepo) |
||
| Line 5: | Line 5: | ||
* '''callbacks for operational data/State callback''' : In sweetcomb, they are registered with method '''GETITEM''' and sysrepo register them with sr_dp_get_items_subscribe(). These are the callbacks triggered by a NETFCONF get RPC with Netopeer2. | * '''callbacks for operational data/State callback''' : In sweetcomb, they are registered with method '''GETITEM''' and sysrepo register them with sr_dp_get_items_subscribe(). These are the callbacks triggered by a NETFCONF get RPC with Netopeer2. | ||
* '''callbacks for configuration data''' : In sweetcomb, they are registered with method '''XPATH''' and sysrepo register them with '''sr_subtree_change_subscribe'''. These are the callbacks triggered by a NETCONF edit-config RPC with Netopeer2. | * '''callbacks for configuration data''' : In sweetcomb, they are registered with method '''XPATH''' and sysrepo register them with '''sr_subtree_change_subscribe'''. These are the callbacks triggered by a NETCONF edit-config RPC with Netopeer2. | ||
| + | |||
| + | == Parsing XPATH == | ||
| + | |||
| + | |||
== Writing a configuration callback == | == Writing a configuration callback == | ||
| Line 12: | Line 16: | ||
* '''SR_EV_VERIFY''' : As it is the only phase which can return an error, in Sweetcomb, this is where VPP configuration happens. | * '''SR_EV_VERIFY''' : As it is the only phase which can return an error, in Sweetcomb, this is where VPP configuration happens. | ||
* '''SR_EV_APPLY''' : Nothing is done for a SR_EV_APPLY in sweetcomb. | * '''SR_EV_APPLY''' : Nothing is done for a SR_EV_APPLY in sweetcomb. | ||
| + | |||
| + | NB: errors are reported to the user with sr_set_error and SR_ERR_* return code. | ||
=== Operations === | === Operations === | ||
| Line 18: | Line 24: | ||
* '''SR_OP_MODIFIED''': | * '''SR_OP_MODIFIED''': | ||
* '''SR_OP_DELETED''': | * '''SR_OP_DELETED''': | ||
| + | |||
| + | == Writing a state callback == | ||
| + | |||
| + | It is the job of the developper to build every XPATH which will be replied to the client. Every reply comes as a pair (xpath, value). | ||
| + | |||
| + | XPATH replied is built with : '''sr_val_build_xpath()''' | ||
| + | The value which goes whith XPATH is built with '''sr_val_'''t array. | ||
| + | |||
| + | The argument '''sr_val_t **values''' and '''size_t *values_cnt''' of the callback must be filled respectively with value array and the number of replies. | ||
Revision as of 15:30, 25 March 2019
Contents
Sysrepo
In our case, there are two types of callbacks we can register
- callbacks for operational data/State callback : In sweetcomb, they are registered with method GETITEM and sysrepo register them with sr_dp_get_items_subscribe(). These are the callbacks triggered by a NETFCONF get RPC with Netopeer2.
- callbacks for configuration data : In sweetcomb, they are registered with method XPATH and sysrepo register them with sr_subtree_change_subscribe. These are the callbacks triggered by a NETCONF edit-config RPC with Netopeer2.
Parsing XPATH
Writing a configuration callback
Events
- SR_EV_VERIFY : As it is the only phase which can return an error, in Sweetcomb, this is where VPP configuration happens.
- SR_EV_APPLY : Nothing is done for a SR_EV_APPLY in sweetcomb.
NB: errors are reported to the user with sr_set_error and SR_ERR_* return code.
Operations
- SR_OP_CREATED:
- SR_OP_MODIFIED:
- SR_OP_DELETED:
Writing a state callback
It is the job of the developper to build every XPATH which will be replied to the client. Every reply comes as a pair (xpath, value).
XPATH replied is built with : sr_val_build_xpath() The value which goes whith XPATH is built with sr_val_t array.
The argument sr_val_t **values and size_t *values_cnt of the callback must be filled respectively with value array and the number of replies.
