Re: [vpp-dev] RFC: Error Codes

[Dave Barach (dbarach)]

Right. The error number base needs to be managed just like the message ID base… 
D.

From: Jon Loeliger [mailto:j...@netgate.com]
Sent: Tuesday, January 23, 2018 9:39 AM
To: Ole Troan <otr...@employees.org>
Cc: Dave Barach (dbarach) <dbar...@cisco.com>; vpp-dev <vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] RFC: Error Codes

On Tue, Jan 23, 2018 at 8:12 AM, Ole Troan 
<otr...@employees.org<mailto:otr...@employees.org>> wrote:
Dear Dave,

> I would be tempted to have the compiler emit 
> "foreach__api_error" macros [or similar]:
>
> #define foreach_foo_api_error \
> _(SUCCESS, "Success") \
> _(ERROR, "This didn't go well")
>
> To minimize pain in upgrading existing C-code...

Ah, yes of course.
Done.
https://gerrit.fd.io/r/#/c/10204/

Cheers,
Ole

Glad to see you guys like the notion!

With this, will plugins have to manage an error number base for
each plugin now?  Or will that be some form of magic behind the scene?

Thanks,
jdl

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] RFC: Error Codes

[Jon Loeliger]

On Tue, Jan 23, 2018 at 8:12 AM, Ole Troan  wrote:

> Dear Dave,
>
> > I would be tempted to have the compiler emit 
> > "foreach__api_error"
> macros [or similar]:
> >
> > #define foreach_foo_api_error \
> > _(SUCCESS, "Success") \
> > _(ERROR, "This didn't go well")
> >
> > To minimize pain in upgrading existing C-code...
>
> Ah, yes of course.
> Done.
> https://gerrit.fd.io/r/#/c/10204/
>
> Cheers,
> Ole


Glad to see you guys like the notion!

With this, will plugins have to manage an error number base for
each plugin now?  Or will that be some form of magic behind the scene?

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] RFC: Error Codes

[Ole Troan]

Dear Dave,

> I would be tempted to have the compiler emit 
> "foreach__api_error" macros [or similar]:
> 
> #define foreach_foo_api_error \
> _(SUCCESS, "Success") \
> _(ERROR, "This didn't go well")
> 
> To minimize pain in upgrading existing C-code...

Ah, yes of course.
Done.
https://gerrit.fd.io/r/#/c/10204/

Cheers,
Ole

> -Original Message-
> From: Ole Troan [mailto:otr...@employees.org]
> Sent: Tuesday, January 23, 2018 5:41 AM
> To: Dave Barach (dbarach) <dbar...@cisco.com>; Jon Loeliger <j...@netgate.com>
> Cc: vpp-dev <vpp-dev@lists.fd.io>
> Subject: Re: [vpp-dev] RFC: Error Codes
> 
> 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

Re: [vpp-dev] RFC: Error Codes

[Dave Barach (dbarach)]

I would be tempted to have the compiler emit "foreach__api_error" 
macros [or similar]:

#define foreach_foo_api_error \
_(SUCCESS, "Success") \
_(ERROR, "This didn't go well") 

To minimize pain in upgrading existing C-code...

D.


-Original Message-
From: Ole Troan [mailto:otr...@employees.org] 
Sent: Tuesday, January 23, 2018 5:41 AM
To: Dave Barach (dbarach) <dbar...@cisco.com>; Jon Loeliger <j...@netgate.com>
Cc: vpp-dev <vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] RFC: Error Codes

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

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] RFC: Error Codes

[Ole Troan]

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

Re: [vpp-dev] RFC: Error Codes

[Dave Barach (dbarach)]

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

[vpp-dev] RFC: Error Codes

[Jon Loeliger]

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