Hello Jan!
On 2023-11-16 09:54, Jan Lindblad (jlindbla) wrote:
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.
This is a really good point which I didn't really appreciate as I'm a
Vimmer. For people with elaborate IDE's, this may be a showstopper and
it's worth avoiding language mixing in the way I originally suggested.
OTOH, there is no reason then to mention the names of C functions
explicitly, it will be probably enough to have a strict naming
convention generating the function names from the tree paths. But these
details are probably out of the scope of this WG; I just wanna say that
it looks like no extensions to the YANG itself will be needed … which is
probably a good outcome.
+ 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.
Well … we'll probably try the same probably with Yangson and let's see
whether we shoot our legs the same way or whether we happen to create a
working framework.
Thank you for your partial map of the minefield, it will be very handy
when sweeping it.
Have a nice day!
Maria
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, towrite 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
--
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
