Dear Ole,

Before we deprecate vat - and the vat plugins - it would be nice to solve
the CLI problem. In particular, to make the "binary-api" debug CLI work in
some reasonable way with vat2. 

I have operational configuration files of considerable length full of stuff
like this:

binary-api mactime_add_del_range name lg-tv mac xxx  allow-static
binary-api mactime_add_del_range name old-mac mac xxy allow-static
binary-api mactime_add_del_range name joe-iphone mac xxz allow-static

I can deal with the problem by converting xxx_test.c code into debug CLI
commands in the affected data-plane plugin(s). Perhaps that's the answer. 

Thoughts?

Thanks... Dave

-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Ole Troan
Sent: Thursday, November 19, 2020 6:44 AM
To: vpp-dev <[email protected]>
Subject: [vpp-dev] RFC: VAT evolution

Hi,

Problems:
 - VAT requires hand-written code for CLI and print routines
 - VAT only supports parts of the API (people have forgotten to add VAT code
when adding new APIs)
 - API trace supports generating "SCRIPT" code for VAT, but that is also
partly supported, and the trace handlers overlap with the "pretty print
handlers.


29890 adds code to autogenerate C functions that convert from API binary
format to JSON and back.
It also completely auto-generates test plugins for VAT2. A simple tool that
takes an API message in JSON, converts it and sends off to VPP, and outputs
the replies back into JSON.

https://gerrit.fd.io/r/c/vpp/+/29890

I chose to use JSON as the "UI", because that is an easy representation of
the relatively complex data-structures API messages have become.
Instead of autogenerating a CLI to create lists for example. Expecting that
the most common usage of VAT would be via a programming language rather than
directly by a human.
Building a CLI front-end on top of VAT2 should be relatively straight
forward though.

As a next step I plan to adjust VPP api tracing to dump in JSON format, so
that it can be interjected back into VPP with VAT2.
That also allows removal of src/tools/vppapitrace and should simplify the
API tracing dump code in VPP.

Longer term I hope for this to replace VAT. That would allow removing of all
the _test.c files in plugins. Remove all the custom_dump functions.
As well as any manually written endian and print handlers.

The JSON representation might open up other possibilities too, but I haven't
explored those in detail. E.g. offer a REST interface directly on top of the
VPP API.

>From my perspective 29890 is ready to go.
What do people think?

Best regards,
Ole


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18094): https://lists.fd.io/g/vpp-dev/message/18094
Mute This Topic: https://lists.fd.io/mt/78362835/21656
Group Owner: [email protected]
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to