SIL Code Access to Metadata

The netconfd-pro server saves all the external language statements it finds, even those it does not recognize. These are stored in the 'ncx_appinfo_t' data structure in ncx/ncxtypes.h.

This data structure is not accessed directly. There are SIL access functions defined in ncx/ncx_appinfo.h (described in the following sections) that allow these language statements to be accessed.

The YANG prefix and extension name are saved
The YANG prefix must be used in the 'find' APIs (not the module name)
If an argument string was provided, it is saved along with the command name.
If extensions are nested then they will be saved as well.
Each appinfo contains a child queue of appinfo to store nested statements

Server Data Structures with Metadata

Several data structures contains an 'appinfoQ' field to contain all the ncx_appinfo_t structures that were generated within the same YANG syntax block (E.g., within a typedef, type, leaf, import statement).

Data Structure	Struct Name	Parent Statement
YANG Module	ncx_module_t	module-stmt or submodule-stmt
Extension	ext_template_t	extension-stmt
Grouping	grp_template_t	grouping-stmt
Feature	ncx_feature_t	feature-stmt
Identity	ncx_identity_t	identity-stmt
Import	ncx_import_t	import-stmt
Include	ncx_include_t	include-stmt
Object	obj_template_t	data-def-stmt
Deviate	obj_deviate_t	deviate-stmt
Deviation	obj_deviation_t	deviation-stmt
Enumeration	typ_enum_t	enum-stmt
Type	typ_def_t	type-stmt
Typedef	typ_template_t	typedef-stmt

Server APIs to Access Metadata

The SIL code should already know which YANG statements to check for specific external statements. The allowed parent YANG statements should be defined in the extension statement.

There are 3 steps the SIL code must follow to access the metadata:

Retrieve the data structure containing the metadata (e.g. obj_template_t). This step is out of scope here. Refer to the YANG Objects section for API functions to access the obj_template_t data structure.
Retrieve the 'appinfoQ' for the data structure
Use ncx_appinfo_t API functions to traverse all metadata or find specific external statements

The following table highlights the SIL functions in ncx/ncx_appinfo.h that allow SIL code to examine any of the non-standard language statements that were found in the YANG module:

API Function	Description
ncx_find_appinfo	Find an ncx_appinfo_t structure by its prefix and name
ncx_find_const_appinfo	Find a const ncx_appinfo_t structure by its prefix and name
ncx_find_next_appinfo	Find the next const ncx_appinfo_t
ncx_find_next_appinfo2	Find the next ncx_appinfo_t

ncx_find_appinfo

ncx_appinfo_t *ncx_find_appinfo(dlq_hdr_t *appinfoQ, const xmlChar *prefix, const xmlChar *varname)

Find an appinfo entry by name (First match is returned) The entry returned is not removed from the Q.

This original code design is very fragile because it relies on the YANG prefix being unique within the server.

This is a customer API to support custom object flags All extensions are stored in the object appinfoQ dusring parsing

Parameters:

appinfoQ -- pointer to Q of ncx_appinfo_t data structure to check
prefix --
module prefix that defines the extension

NULL to pick the first match (not expecting appinfo name collisions)
varname -- name string of the appinfo variable to find

Returns:

pointer to the ncx_appinfo_t struct for the entry if found NULL if the entry is not found

Example showing non-const appinfo usage:

dlq_hdr_t *appinfoQ = obj_get_datadefQ(obj);
ncx_appinfo_t *appinfo =
    ncx_find_appinfo(appinfoQ,
                     (const xmlChar *)"acme",
                     (const xmlChar *)"my-extension");
if (appinfo) {
    if (appinfo->value) {
        // this string contains the extension parameter value
    }
}

ncx_find_const_appinfo

const ncx_appinfo_t *ncx_find_const_appinfo(const dlq_hdr_t *appinfoQ, const xmlChar *prefix, const xmlChar *varname)

Find an appinfo entry by name (First match is returned) The entry returned is not removed from the Q (CONST version)

Parameters:

appinfoQ -- pointer to Q of ncx_appinfo_t data structure to check
prefix --
module prefix that defines the extension

NULL to pick the first match (not expecting appinfo name collisions)
varname -- name string of the appinfo variable to find

Returns:

pointer to the ncx_appinfo_t

struct for the entry if found

NULL if the entry is not found

Example showing const appinfo usage:

dlq_hdr_t *appinfoQ = obj_get_datadefQ(obj);
const ncx_appinfo_t *appinfo =
    ncx_find_const_appinfo(appinfoQ,
                           (const xmlChar *)"acme",
                           (const xmlChar *)"my-extension");
if (appinfo) {
    if (appinfo->value) {
        // this string contains the extension parameter value
    }
}

mcx_find_next_appinfo

const ncx_appinfo_t *ncx_find_next_appinfo(const ncx_appinfo_t *current, const xmlChar *prefix, const xmlChar *varname)

Find the next instance of an appinfo entry by name (First match is returned) The entry returned is not removed from the Q.

Parameters:

current -- pointer to current ncx_appinfo_t data structure to check
prefix --
module prefix that defines the extension

NULL to pick the first match (not expecting appinfo name collisions)
varname -- name string of the appinfo variable to find

Returns:

pointer to the ncx_appinfo_t

struct for the entry if found

NULL if the entry is not found

This API function is used after the 'ncx_find_const_appinfo' API function to find an extension used multiple times within the same parent statement.

Example showing const appinfo usage:

// using appinfo from ncx_find_const_appinfo
while (appinfo) {
    if (appinfo->value) {
        // this string contains the extension parameter value
    }

    appinfo = ncx_find_next_appinfo(appinfo,
                                    (const xmlChar *)"acme",
                                    (const xmlChar *)"my-extension");
}

ncx_find_next_appinfo2

ncx_appinfo_t *ncx_find_next_appinfo2(ncx_appinfo_t *current, const xmlChar *prefix, const xmlChar *varname)

Find the next instance of an appinfo entry by name (First match is returned, not const version) The entry returned is not removed from the Q.

Parameters:

current -- pointer to current ncx_appinfo_t data structure to check
prefix --
module prefix that defines the extension

NULL to pick the first match (not expecting appinfo name collisions)
varname -- name string of the appinfo variable to find

Returns:

pointer to the ncx_appinfo_t

struct for the entry if found

NULL if the entry is not found

This API function is used after the 'ncx_find_appinfo' API function to find a non-const extension used multiple times within the same parent statement.

Example showing non-const appinfo usage:

// using appinfo from ncx_find_appinfo
while (appinfo) {
    if (appinfo->value) {
        // this string contains the extension parameter value
    }

    appinfo = ncx_find_next_appinfo2(appinfo,
                                     (const xmlChar *)"acme",
                                     (const xmlChar *)"my-extension");
}