Check the Online Manual for Up to Date Information
This lesson will show you the various components of YANG modules and the corresponding SIL functions and structures.
Pre-Requisites
You should have installed YumaPro SDK "YumaPro Installation Guide” and finished "Prepare a YANG module”.
YANG objects: container, list and choice
Typically, YANG module starts with a Container object which may contain list objects, more container objects and/or choice objects. As an example, let us take a look at the following YANG module schema that can be connected to ietf-interfaces YANG module (YANG module attached).
If you look at the ietf-interfaces YANG module:
ietf-interfaces.yang outline:
YANG module header information
...
/*
* Configuration data nodes
*/
container interfaces {
...
}
/*
* Operational state data nodes
*/
container interfaces-state {
config false;
...
container statistics {
...
}
}
...
You will notice it has two containers: interfaces, which is for interface configuration data, and interfaces-state, which is for interface operational state data. The YANG statement config false declares that interfaces-state is not configuration data. The container interfaces-state includes a third container, statistics, which inherits config false from its parent container. All of these containers have a collection of nodes and leafs inside them.
 | For more details see the YANG Objects / Object Trees section of YumaPro Server Overview and the IETF YANG 1.1 RFC 7950 |
If you look at the generated SIL code file, u_ietf-interfaces.c, you will notice it has an outline structure that is very similar to the YANG module. There is a function that is called to retrieve the data for each container and a source code “stub” for each leaf in the container. For example the operation state data containers:
ietf-interfaces.yang - nodes | u_ietf-interfaces.c - stubs |
| Container interfaces | u_ietf_interfaces_interfaces_edit() |
| List interface | u_ietf_interfaces_interfaces_interface_edit() |
| Container interfaces-state | u_ietf_interfaces_interfaces_state_interface_get() |
| Container's Leafs | Stub code that loops through all the leafy children |
| List interface | u_ietf_interfaces_interfaces_state_interface_get() |
| List's Leafs | Stub code that loops through all the leafy children |
| Container statistics | u_ietf_interfaces_interfaces_state_interface_statistics_get() |
| Container's Leafs | Stub code that loops through all the leafy children |
The attachment archive contains an auto generated code for ietf-interfaces YANG module for your reference. It was not modified and does not have any specific instrumentation. To create the instrumentation to hook the YANG module leafs to the server (for example to get all the counter values), code that will retrieve the values needs to be added to the stubs in the source code.
YumaPro SDK Instrumentation Functions: edit2 and get2
You probably noticed that when make_sil_dir_pro was run in the previous lesson "Prepare a YANG module" that several parameters were supplied, including --sil-get2 and --sil-edit2. These parameters signal make_sil_dir_pro to generate the SIL code with Yuma Pro SDK’s 2nd generation callbacks for operational and configuration data.
edit2
The SIL instrumentation stubs for configuration data use edit2 callbacks to provide a common set of access functions regardless of the actual database model being accessed, for example candidate or running configuration. Edit2 uses a common configuration database template which provides functions to access configuration databases.
| edit2 will be covered in more detail later on in these lessons. Details on edit2 can be found in the Database Operations section of the YumaPro Developer Manual. |
get2
Get2 callbacks provide mechanisms in the get2 template for the SIL stub code to access operational data from the server.
| get2 will be covered in more detail later on in these lessons. Details on get2 can be found in the Operational Data section of the YumaPro Developer Manual |
Now, we covered all the stub callback functions. In the next step we are going to illustrate how the stub code may be modified and then built and loaded into the server.