This lesson will show you the various components of YANG modules and the corresponding SIL functions and structures.


You should have completed "Installing YumaPro SDK” and "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 YumaPro Developer Manual section 4.3.2  “Yang Object Tree” 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
    List interface
Container interfaces-stateu_ietf_interfaces_interfaces_state_interface_get()
    Container's Leafs
    Stub code that loops through all the leafy children
    List interface
        List's Leafs
    Stub code that loops through all the leafy children
        Container statisticsu_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. 


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.

For more details see the YumaPro Developer Manual section called Database Operations and section Database Access Functions


Get2 callbacks provide mechanisms in the get2 template for the SIL stub code to access operational data from the server.

For more details see the YumaPro Developer Manual section Operational Data

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 build and loaded to the server.

Next Lesson: Building and Installing the SIL