YumaWorks

The enumeration built-in type represents values from a set of assigned names.

The "enum" statement, which is a substatement to the "type" statement, MUST be present if the type is "enumeration".  It is repeatedly used to specify each assigned name of an enumeration type. It takes as an argument a string that is the assigned name. The string MUST NOT be zero-length and MUST NOT have any leading or trailing whitespace characters (any Unicode character with the "White_Space" property).  The use of Unicode control codes SHOULD be avoided.

The statement is optionally followed by a block of substatements that holds detailed enum information. All assigned names in an enumeration MUST be unique.

When an existing enumeration type is restricted, the set of assigned names in the new type MUST be a subset of the base type's set of assigned names. The value of such an assigned name MUST NOT be changed.

The "value" statement, which is optional, is used to associate an integer value with the assigned name for the enum. This integer value MUST be in the range -2147483648 to 2147483647, and it MUST be unique within the enumeration type.

If a value is not specified, then one will be automatically assigned. If the "enum" substatement is the first one defined, the assigned value is zero (0); otherwise, the assigned value is one greater than the current highest enum value (i.e., the highest enum value, implicit or explicit, prior to the current "enum" substatement in the parent "type" statement).

Note that the presence of an "if-feature" statement in an "enum" statement does not affect the automatically assigned value.

If the current highest value is equal to 2147483647, then an enum value MUST be specified for "enum" substatements following the one with the current highest value.

When an existing enumeration type is restricted, the "value" statement MUST either have the same value as in the base type or not be present, in which case the value is the same as in the base type.

Usage Example

Consider the following YANG module example. Refer to the attachments:

module enum-test {
  namespace "http://netconfcentral.org/ns/enum-test";
  prefix "et";

  revision 2020-05-15 {
    description "Init example module.";
  }

  typedef slot-index {
    type enumeration {
      enum zero {
        value 0;
        description
          "Reserved slot number.";
      }
      enum lm1 {
        value 1;
        description
          "Slot 1.";
      }
      enum lm2 {
        value 2;
        description
          "Slot 2.";
      }
      enum lm3 {
        value 3;
        description
          "Slot 3.";
      }
      enum lm4 {
        value 4;
        description
          "Slot 4.";
      }
      enum lm5 {
        value 5;
        description
          "Slot 5.";
      }
      enum lm6 {
        value 6;
        description
          "Slot 6.";
      }
    }
    description
      "Example enumeration";
  }

  container conf-cont {
    presence "testing one";

    leaf index {
      type slot-index;
    }
  }

  container state-conf {
    config false;

    leaf index {
      type slot-index;
    }
  }
}

The following API can be used with the bits type val value node. Refer to val.h:

• VAL_ENUM(): Macro that returns integer value of the enumeration;
• VAL_ENUM_NAME(): Macro that returns string value of the enumeration;
• val_make_simval_obj(): Function that malloc a new val value node and does not need to know the type, it will be picked automatically based on the provided object type.

EDIT2 Callback example

Following code snippet illustrates how to access enumeration type val value node values in EDIT2 callback.

This is just an example of how the following API can be used. Refer to attached SIL code for complete example:

    case AGT_CB_COMMIT:
        /* device instrumentation done here */
        switch (editop) {
        case OP_EDITOP_LOAD:
            break;
        case OP_EDITOP_MERGE:
            break;
        case OP_EDITOP_REPLACE:
            break;
        case OP_EDITOP_CREATE:
            {
                val_value_t *child_enum =
                    val_find_child(newval,
                                   y_enum_test_M_enum_test,
                                   (const xmlChar *)"index");
                if (child_enum) {
                    int32 value = VAL_ENUM(child_enum);
                    const xmlChar *name = VAL_ENUM_NAME(child_enum);

                    log_debug2("\nENUM value:%u; ENUM name:%s",
                               value,
                               name);
                }

                /**** process other child edits here if needed ****/

            }
            break;
        case OP_EDITOP_DELETE:
            break;
        default:
            res = SET_ERROR(ERR_INTERNAL_VAL);
        }

So during the <edit-config> during COMMIT Phase the server will invoke this EDIT2 callback for the container with enumeration leaf and will hit the above code.

The <edit-config> may look as follows:

  <edit-config>
    <target>
      <candidate/>
    </target>
    <default-operation>merge</default-operation>
    <test-option>set</test-option>
    <config>
      <conf-cont xmlns="http://netconfcentral.org/ns/enum-test">
        <index
          xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
          nc:operation="create">lm4</index>
      </conf-cont>
    </config>
  </edit-config>

The server might output the following logging information to the standard output during the COMMIT Phase after <commit> operation:

***** start commit phase on running for session 3, transaction 96209 *****

Start full commit of transaction 96209: 1 edit on running config
Start invoking commit SIL callback for create on enum-test:conf-cont
Enter enum_test_conf_cont_edit callback for commit phase

VAL name:index; ENUM value:4; ENUM name:lm4

Finished invoking user callback on enum-test:conf-cont
edit-transaction 96209: on session 3 by tony@127.0.0.1
  time: 2020-05-15T17:33:35Z
  message-id: 3
  trace-id: --
  datastore: running
  operation: create
  target: /et:conf-cont
  comment: none

GET2 Callback example

The following code snippet illustrates how to create an enumeration type val value node in GET2 callbacks.

This is just an example of how the following API can be used. Refer to attached SIL code for complete example:

    /* go through all the requested terminal child objects */
    obj_template_t *childobj =
        getcb_first_requested_child(get2cb, obj);
    for (; childobj; childobj =
        getcb_next_requested_child(get2cb, childobj)) {

        const xmlChar *name = obj_get_name(childobj);
        val_value_t *retval = NULL;

        /* Retrieve the value of this terminal node and
         * add with getcb_add_return_val */

        if (!xml_strcmp(name, y_enum_test_N_index)) {
            /* leaf index (enumeration) */
            retval =
                val_make_simval_obj(childobj,
                                    (const xmlChar *)"lm5",
                                    &res);
            if (retval) {
                getcb_add_return_val(get2cb, retval);
            } else {
                return res;
            }
        }
    }

So during the <get> operation the server will invoke this GET2 callback for the container with enumeration leaf and will return created value of this enumeration.

The <get> RPC may look as follows:

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get>
    <filter type="subtree">
      <state-conf xmlns="http://netconfcentral.org/ns/enum-test"/>
    </filter>
  </get>
</rpc>

The server might reply with the following data:

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
 <data>
  <state-conf xmlns="http://netconfcentral.org/ns/enum-test">
   <index>lm5</index>
  </state-conf>
 </data>
</rpc-reply>