Hi Evan,
A couple of comments/questions...
In the design doc/scope section you state:
> We will not provide the overall library for handling errors and
> logging as described in the Caiman Unified Design (CUD) documents.
> - However the design here is such that the code will be generic
> enough that moving into something that will fit with CUD
> will be easier.
But, aren't you proposing now that you will provide the library for
error handling for Caiman?
I think logging needs to be in scope, especially since the scope of this
work has expanded to producing a general purpose error library for all
Caiman consumers.
Is there a specific format to the error table consumers need to register?
> union {
> int es_err_num;
> int es_op_num;
> int es_failed_at;
> int es_fixit_str_num;
> char *es_failed_str[MAXLEN];
> } es_data;
Why is this defined as a union and not just members of the err_data
structure?
I understand why the err_info structure has a union defined for specific
err_data_t members, but not sure why this is done this way.
> This project will provide for the ability to return a an nvlist of
> information describing a failure and it's context from calls into libbe.
In looking at the defined interfaces for getting errors:
> /* get the error list of all errors */
> err_info_list_t *es_get_all_errors();
We are returning a list of error_info structures, rather than an
nv_list. Am I missing something? Maybe these are defined for use by
other libraries, but consumers use a different set of interfaces?
> /* Free the error list and elements */
> void es_free_errors()
Who keeps track of the errors to free? Shouldn't we pass the list of
errors in?
> * Free the error list */
> void es_free_err_info_list(err_info_list_t *list)
How is this different than the above? We have to free the elements in
the list no matter what, right?
> eliverables:
> - In addition to library changes to support the components mentioned
> above we will need to add the following:
> - Addition of code that will try to determine what the user may need
> to do to correct the problem.
I assume this is a deliverable for libbe only? Is this part of the error
table data provided per consumer?
> Addition of a handle that will be passed back from library calls.
> This handle will contain the error, cleanup and corrected error
> information. Accessor functions will be used to retrieve the error
> information out of the error structures attached to this handle.
So, is there a set of interfaces that are provided for consumers, not
listed in this document, that they use to get this information?
thanks,
sarah
*****
Evan Layton wrote:
> Ethan and I sat down last week to talk about the structures and error
> handling I described in the previous design. While what was described
> would work well for beadm/libbe it was not quite general enough for
> use with other consumers such as AI. In order to come up with a more
> general error handling service or library we've updated the BE
> observability to include this.
>
> The main area of changes are that instead of just providing the
> structures inside libbe we will be creating a new library that can be
> used by consumers such as libbe and AI. It is also expected that this
> library could be used by the unified design. The library will provide
> extensible structures encapsulated within the library. This
> information will be accessed through a set of functions for setting
> error information as well as for retrieving and translating that
> information. The ability will also be provided to do a translation
> from enumerations to descriptive strings based on tables the consumer
> defines as registers with the library.
>
> The updated design has been attached.
>
> Thanks,
> -evan
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> caiman-discuss mailing list
> caiman-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
