Skip to content

Latest commit

 

History

History
126 lines (85 loc) · 3.68 KB

TODO.md

File metadata and controls

126 lines (85 loc) · 3.68 KB
Raw

  • Internal structure of statements, and of the schema node tree.

    This applies both to the stmt tree (tree of tuples returned from yang_parse), and to the #sn{} tree.

    Benchmark: with big.yang (7M), sending the #module{} between processes aborts the emulator:

    HUGE size (87360549654)
Aborted (core dumped)

    Sending the stmt tree for the same module seems to work just fine, so maybe it is ok to keep the stmt as one term, but use something else for the schema node tree.

    Suggestion: see if tts can be used.

    The module's schema tree could be one tts. But should also each grouping and each augment have its own tts of children?

    Owner: seb

  • W3C regexp as a separate application in a separate git repo.

    Take tail-f's nif and put on github.

    Owner: seb

  • Type handling, including run-time support

    We need an erlang representation of every type definition. This erlang representation could be used in compile time but also in run time to validate values against the type.

    The current (unused! unfinished!) code is in yang_types.erl.

    The type code must check the restrictions for given the type. For example, this is illegal:

    typedef foo {
  type string;
}
leaf bar {
  type foo {
    range "1..10";  // illegal; foo is a string type
  }
}

    In order to be useful in run time, we need erlang representations of all built-in types, and also of some derived types. For example, a string can be representated as a binary, a boolean as 'true' or 'false', and an inet:ipv4-address as a 4-tuple.

    In must be possible for plugins to register their own types, including the erlang representation and validation functions. Also plugins need to be able to register their own restriction statements on types.

    Owner: mbj - describe the problem (started with the text above)

  • Plugin architecture

    See pyang's plugins. plugins must be able to:

    • Register grammar

    • Register special handling of types

      As an example, it must be possible for a plugin to validate this:

      leaf foo {
  type uint32 {
    tailf:step 10; // 0,10,20,30,...
    default 11; // error
  }
}

    • Hook into the validation code at well-defined places (doesn't have to be as flexible as pyang)

    • Add data to schema nodes (see #sn.pmap).

    • Register error codes (typically generated by the plugin's validation code.

    • Register XPath functions which then are allowed in must / when expressions.

    Owner: mbj

  • scanner / parser / grammar validation

    Try to merge tony's parser into current code.

    It must be possible for plugins to register their own extension statements; see c_src/yang_grammar.h, functions yang_install_arg_types() and yang_install_grammar().

    As another example, see pyang_plugin_init() in pyang's plugins/smi.py.

    One option could be just to move the file I/O from mbj's NIF up to erlang.

    Owner: tony

  • test cases

    Idea for testing errors: write modules with errors, and annotate the module with the error code, e.g.:

    leaf foo {
  type int32;
  default 'bad'; // ERR_BAD_TYPE
}

    Let the test suite run the validator and check that all errors are reported with correct error codes.

    Even better would be use the same error codes as pyang, and do the same kind of tests in pyang. Then we could resue test cases between this code and pyang. This may require updating pyang with better error codes...

    Owner: None