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:

  1. 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.

  2. Retrieve the 'appinfoQ' for the data structure

  3. 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");
}