1.in current yang, there is “item” field under the supported-reference-types list and sync-state under sync-status. So can you please help me in understanding the sample code.
the get_elem() function can provide a callback to all the config false leaf of sync-status But for the supported-reference-types list, we need to use the get_next() function. Let me know whether my understanding is correct or not.
yes - if your YANG has some lists (or leaf-lists), you to implement get_next() callback too.
There are more examples or similar implementations in other examples, try grepping for confd_data_reply_next_key that is to be used as a response inside get-next()…
(or, manual pages for nice description.details again)
Some of other examples are not data providers but transformations, but principle is almost same.
2.what is the use case of s_init() & s_exit() function.
Sort of typical constructor/destructor of data provider transaction.
Inside this intro example, it just prepares/cleans the internal in-memory “database”/structures that keep example operational data, to provide values to ConfD whenever it invokes callbacks…
If you need e.g. user session specific allocations/work, you can do it here, etc.
3.What’s the main use of confd_register_data_cb function…I have gone through the user guide but didn’t able to understand.
With this function, you tell ConfD:
- use this confd_data_cbs structure (input parameter of function) whenever someone wants to do stuff with YANG data managed by the callpoint.
(i didnt write “read data”, because this same procedure can be used to register RO data provider callpoints, but also RW transformation callpoints)
Callpoint name is part of input parameter, so you can register many different callpoints if you need/want, and separate code for different parts of YANG model.
confd_data_cbs is a wrapper for set of callback procedures that you must implement (get_elem(), get_next(), …).
Depending on how your YANG model looks, you need to implement some of (or even all) of various callbacks… e.g. you need:
-
get_elem() - if you have some leaves (which is usually always 
)
-
get_next() - if you have lists or leaf-lists in YANG
-
get_case() - if you have choice statements
etc.
In your YANG, you can put same callpoint (e.g. tailf:callpoint "helloCp";") to several different places. e.g. to two different leaves, one list, and other places, no problem…
When the callback code is invoked by ConfD, you will have input parameters of callback.
This will tell you for which element specifically you need to create the response…
Nice description of each callback and parameters etc. in man page for:
int confd_register_data_cb(struct confd_daemon_ctx *dx, const struct confd_data_cbs *data);
Best way to play with DP (data provider) implementation is IMHO to print/see all the input parameters of callback procedures (like get_elem(), get_next(), exists_optional(), etc.) to see the which types of “questions” come from confd, and how it depends on YANG model.
Plus if you do not have some of the callpoints registered, but confd needs it, you will see complaints in confd-library log in your app, or in confd devel log.
