Dave, Jon,
> On 22 Jan 2018, at 19:34, Dave Barach (dbarach) <dbar...@cisco.com> wrote:
>
> 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.That makes sense to me too (wonder why we haven't done that before. ;-)) Here is the patch to the compiler: https://gerrit.fd.io/r/10204 VPPAPIGEN: Error definitions VPPAPIGEN: Error definitions This commit adds support for defining errors. errors { SUCCESS, "No error"; ERROR, "This didn't go well"; }; Which results in the following C: vl_error(VL_API_ERROR_SUCCESS, "No error") vl_error(VL_API_ERROR_ERROR, "This didn't go well") And JSON: "errors": [ [ "SUCCESS", "No error" ], [ "ERROR", "This is wrong" ] ] Does that seem sane? Cheers, Ole > > 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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
