Hi Maria, Thanks for reaching out and explaining your plans. I think the approach with basing your interface on a YANG module is excellent. We have been doing similar things massively since more than decade ago, and there a re a couple of caveats I would like to point out:
+ Using YANG extension statements to tie your interface to your code works great. Actually writing the code in the YANG module extension bodies works, but is rather cumbersome. The support you would normally get from an IDE for writing or debugging your C code is easily lost or complicated. So I would recommend tying the code with the interface using extension statements that just mention the name of C functions or C data structures, etc. + Code generation based on YANG works well if the number and size of the YANG modules is modest, e.g. when only your own project YANG modules are in scope. If you want to do this sort of code generation for an entire router or controller, for example, the code generated often gets incredibly large. As an example of this you could look at the many attempts to generate OpenAPI/Swagger APIs from YANG (one example: https://github.com/bartoszm/yang2swagger). Even with the limited support provided by these tools, my experience with this approach has invariably ended with "Code too large" error messages from the compiler. If you want to support larger (sets of) YANG modules, maybe treating the YANG structures more as a data structure rather than a code skeleton would make sense. As in letting methods use paths to YANG elements as arguments, rather than having a separate function call for every element. + For parsing YANG and generating either data structures or code, I find both pyang (easier) and yanger (faster) an excellent base for the job. Their plug-in architecture makes it easy to add your own extensions. Takes a day or two to understand how, but after that initial learning curve, I find them very useful. Best Regards, /jan On 16 Nov 2023, at 09:09, Maria Matejka <[email protected]> wrote: Dear Netmod WG, 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 -- Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o. _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
