Hi -
On 2023-11-16 12:09 AM, Maria Matejka wrote:
...
we're currently trying to create a YANG-described API for BIRD. The
interface will be (at least) one large C file generated from the YANG
files, as we want the implementation to be directly tied to the
specification. What we're aiming to do, though, is to have the code
generator as simple as possible, maybe even completely
language-agnostic, and putting pieces of C code directly into our YANG
files.
Reasons why to do it this way, finally boil down to this:
* we don't want BIRD to have any additional layer of data structures
between API and internals, so there will be specific code for most
of the YANG tree nodes anyway
* we also want to provide the clients with a semantics-aware
interface, to e.g. canonically format the structured data for
human-readable output
There is an alternative approach, to write a separate generator for each
usecase. We haven't decided yet whether it is viable for us. What I
personally see most valuable on the YANG extension approach, is a
possibility to easily ship and update access libraries with a native
object model for each supported language. (If you smell a new Bison from
this, you are quite right.)
My major question is for now, whether there is any work or thoughts in
this direction; I couldn't find any but it may be just my bad search skill.
Then it depends → if this approach has already been proven wrong, please
point me to the discussion to learn how to do the right way. Otherwise,
would there be any interest on designing a canonical extension to the
YANG syntax? I would call it somehow like YANG-With-Embedded-Code
(YWEC), which could be then processed by toolings, generating the "bare"
YANG and all the code files from one normative YWEC.
Thank you all for considering this topic.
Maria and the BIRD Team
...
We had considerable experience with code generation for GDMO and SMIv2
models in the CMIP and SNMP spaces going back to the late 1980s.
We found the most manageable approach for the spaces we were working in
was to leave the model files essentially untouched, and to use separate
files in a custom language to bind the model to the implementation in
the cases where automatically-generated code wouldn't suffice, and to
generate separate C-language files for each input model file.
The deciding factor in all this was configuration management, in the
non-YANG sense of the term. Tracking revisions / updates to modified
model files quickly becomes very messy. Separating them (modules from
each other, and modules from binding from implementation) makes the
configuration management and concomitant regression testing much more
manageable. Generating separate, configuration-managed source code
files is also an important step if the final product set is to have
separable components (think marketed add-ons or options removed when
not needed in a constrained environment) or operate in a subagent
("mount") implementation architectures.
Just my $0.02
Randy
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
