YumaWorks

It is strongly recommended that developers use the supplied doxygen HTML documentation to learn the YumaPro APIs and how to access additional technical support resources. Doxygen is supported both online and can also be generated on a local machine if an SDK package or source code package is installed.

The YumaPro YANG instrumentation libraries, SIL and SIL-SA code, generated by yangdump-sdk have built-in doxygen browser support.

Online Version

The output for the latest YumaPro release is available online

• https://www.yumaworks.com/pub/doxygen/latest/html/index.html

Local Version

See the YumaPro YumaPro Developer Manual and YumaPro yangdump-pro Manual manuals for further instructions on installing and using doxygen for either a YumaPro source code or binary SDK package.

Doxygen Group Structure

Doxygen uses a simple hierarchy to create the ‘Modules’ section of the WEB pages for the source code.

• This hierarchy is hard-wired at this time.

• The top-level group is called “yang-library” and the brief description is simply “YANG Library”.

  • The “ingroup” command for the auto-generated code will use this value

• The 2nd-level group depends on the code that is being generated. There are parts to the group name

  • “sil-” or “silsa-” depending on code for SIL or SIL-SA

  • module name or bundle name

• If the generated source file is for a module within a bundle, then there will be a 3^rd level of grouping.

  • Each module will have a grouping within the bundle grouping

Example tree for SIL code for “module1”

 +-- yang-library
     +
     |
     +-- sil-module1

Example tree for SIL-SA code for “bundle1”

 +-- yang-library
     +
     |
     +-- silsa-bundle1

Example tree for SIL-SA code for “module1” and “module2” within “bundle1”

+-- yang-library
     +
     |
     +-- silsa-bundle1
         +
         |
         + silsa-bundle1-module1
         + silsa-bundle1-module2

Example Doxygen Headers

New GET2 callback for interface statistics:

/**
 * @brief Get database object callback for container statistics (getcb_fn2_t)\n
 * Path: container /interfaces/interface/statistics\n
 *
 * Fill in 'get2cb' response fields.
 *
 * @param get2cb GET2 control block for the callback.
 * @param k_if_name Ancestor key leaf 'name' in list 'interface'\n
 * Path: /if:interfaces/if:interface/if:name
 * @return return status of the callback.
 */
extern status_t u_if_statistics_get (
    getcb_get2_t *get2cb,
    const xmlChar *k_if_name);

New EDIT2 callback for interface:

/**
 * @brief Edit database object callback (agt_cb_fn_t)\n
 * Path: list /interfaces/interface
 *
 * @param scb session control block making the request
 * @param msg message in progress for this edit request
 * @param cbtyp callback type for this callback
 * @param editop the parent edit-config operation type,
 * which is also used for all other callbacks
 * that operate on objects.
 * @param newval container object holding the proposed changes
 * to apply to the current config, depending on
 * the editop value. Will not be NULL.
 * @param curval current container values from the "<running>"
 * or "<candidate>" configuration, if any. Could be NULL
 * for create and other operations.
 * @param k_if_name Local key leaf 'name' in list 'interface'\n
 * Path: /if:interfaces/if:interface/if:name
 * @return return status for the phase.
 */
extern status_t u_if_interface_edit (
    ses_cb_t *scb,
    rpc_msg_t *msg,
    agt_cbtyp_t cbtyp,
    op_editop_t editop,
    val_value_t *newval,
    val_value_t *curval,
    const xmlChar *k_if_name);