This lesson will show you the various top-level 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

Every YANG module starts with a Container object which may contain list objects, more container objects and/or choice objects.

If you look at the ietf-interfaces.yang file:

    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 3.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-state
  name of leaf  name of stub
  leaf type
  /* leaf type (identityref) */
    Other leafs: admin-status, oper-status, last-change, if-index, phys-address, higher-layer-if, lower-layer-if, speed

container statistics
  name of leaf
  name of stub
  leaf discontinuity-time
  /* leaf discontinuity-time (string) */
    Other leafs: in-octets, in-unicast-pkts, in-broadcast-pkts, in-multicast-pkts, in-discards, in-errors, in-unknown-protos, out-octets, out-unicast-pkts, out-broadcast-pkts, out-multicast-pkts, out-discards, out-errors

To create the instrumentation to hook the YANG module leafs to the server, code 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 6.6  Database Operations and section 6.6.3  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 6.9 Operational Data

Next Lesson: Building and Installing the SIL