Step 1: Define a common YANG module
The operations and database contents are defined in a YANG data model module. The SIL code for this module will be protocol and encoding independent, providing NETCONF, RESTCONF, and CLI interfaces for the content defined in the YANG module.
Step 2: Generate the SIL code stubs
To generate the source files for a YANG module named ‘address’, use the ‘make_sil_dir_pro’ script. This uses yangdump-pro to generate the individual C and H files.
make_sil_dir_pro –split address
The file y_address.c contains the glue code to hook the user callback code into the transaction engine. This file should never be edited.
The file u_address.c contains the user callback functions needed to hook the YANG defined configuration data to the underlying system. The code stubs in this file typically contain system-specific function calls to commit database changes.
Step 3: Decide which transaction phases need user callback functions.
- Validate Phase: A user callback is only needed here if system validation or “description statement” validation is required. All machine-readable YANG statements related to validation are handled automatically by the transaction engine. The validate phase has to complete without error for all modified object instances. No system resources should be allocated or modified during this phase.
- Apply Phase: A user callback is only needed here if system resource reservation is supported. The target database is modified by the transaction engine using fully recoverable edits, whether that is the candidate or running database. The user callback code may support recoverable resource reservation during this phase. After this callback is invoked, either the commit or rollback phases will follow, allowing the user callback code to commit or cleanup any system resources.
- Commit or Rollback Phase: A user callback for the commit phase is needed to apply configuration changes to the system. Once the commit callback has been done for an object instance, no further callbacks will be done for the current transaction. Either the commit callback or the rollback will be invoked, but not both. The transaction engine will construct a new edit to undo configuration changes if a commit partially finishes and some completed edits need to be rolled back.
Step 4: Hook your system callbacks into the edit function.
