Dear Jon,
That makes sense to me. Hopefully Ole will comment with respect to adding
statements of the form
error { FOO_NOT_AVAILABLE, “Resource ‘foo’ is not available } ;
to the new Python PLY-based API generator.
The simple technique used to allocate plugin message-ID’s seems to work OK to
solve the analogous problem here.
Thanks… Dave
From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On
Behalf Of Jon Loeliger
Sent: Monday, January 22, 2018 12:13 PM
To: vpp-dev <vpp-dev@lists.fd.io>
Subject: [vpp-dev] RFC: Error Codes
Hey VPP Aficionados,
I would like to make a proposal for a new way to introduce error codes
into the VPP code base. The two main motivations for the proposal are
1) to improve the over-all error messages coupled to their API calls,
and
2) to clearly delineate the errors for VNET from those of various plugins.
Recently, it was pointed out to me that the errors for the various plugins
should not introduce new, plugin-specific errors into the main VNET list
of errors (src/vnet/api_errno.h) on the basis that plugins shouldn't clutter
VNET, should be more self-sustaining, and should stand alone.
Without a set of generic error codes that can be used by the various plugins,
there would then be no error codes as viable return values from the API calls
defined by plugins.
So here is my proposal:
- Extend the API definition files to allow the definition of error messages
and codes specific to VNET, or to a plugin.
- Each plugin registers its error codes with a main registry upon being
loaded.
- The global error table is maintained, perhaps much like API enums today.
- Each API call then has a guaranteed set of return values defined directly
within its own API definition, thus coupling API calls and their possible
returned error codes as well.
Other thoughts?
Thanks,
jdl
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
