Sarah Jelinek wrote:
> Hi Evan,
>
> I have a couple of comments/questions:
>
>> The logging side of things is outside the scope of this project and will
>> be done as part of the Caiman Unified Design project. That being
>> said we
>> can see the possibility for two types or levels of logging that may be
>> needed. The first is logging that the consumer of the library will do.
>> This will be based on the information returned through the library's
>> handle.
>> There is also the need for some debugging form of logging this will be
>> done inside the library.
>
>
> Is there any reason we can't use the current logging library, liblogsvc,
> to do logging for this now?
Yes, doing the logging work is outside the scope of this project at this time.
>> typedef struct be_handle {
>> err_info_t *be_err_info; /* information for the actual
>> failure */
>> err_info_t *be_cleanup_info; /* information on any needed
>> cleanup */
>> err_info_list_t *be_fixed_err_info; /* list of errors fixed
>> internally */
>> ....
>> } be_handle_t;
>
>
> Is there any reason that this handle has to be BE specific? If the
> library is going to populate the error_info_t structures, it seems to me
> we can make the handle general enough for use by multiple consumers.
The handle is specific to the libbe library. The error structures are
what would be shared. It's up to whoever ends up using these structures
to decide how to pass them back into and out of their own library.
>
>> Public Functions:
>> These functions are used to access the fields in the data structure as
>> the err_info structure itself will be encapsulated within the library.
>>
>> /* retrieves error information */
>> int be_get_err_info(err_info_t *be_err_info, nvlist_t *be_err_info);
>>
>> /* retrieves any cleanup information needed due to error */
>> int be_get_cleanup_info(err_info_t *be_cleanup_info, nvlist_t
>> *be_err_info);
>>
>> /* closes the library handle and frees up the error and clean-up
>> information. */
>> int be_close_handle (be_handle_t *be_hd);
>
>
> Also, can these be made general for use by multiple consumers? i.e.
> error_get_err_info()..
Why? Since these are only being used by libbe and consumers of libbe
and the fact that the handle is specific to libbe I don't think it
would be very useful to provide this same level of accessor function
beyond libbe. However any functions used inside the library to fill
in the error structures with this error information could definitely
be made more general but that's not something I will be exporting as
part of this project.
>
> Also, I am assuming that within libbe, or any other caller that uses
> this, the initial error would allocate the memory and fill in its parts
> of the data structure. Then, as it is returned to the caller, the caller
> would modify the data structure as appropriate to provide more context?
> So, the filling in of the data structure is in reverse order?
>
> For example:
> -libbe ->
> -Uses getters to get error data.
> Processes as appropriate
> be_foo ->
> -Same as be_bar()
> be_bar->
> -gets 'handle' from call to
> be_baz()
> -Adds additional information
> to nvlist?
> -Returns handle to be_foo()
>
> be_baz->
> -error occurs
> -allocation of handle
> -fill in error data
>
>
>
> Is this correct? If it is, it means that the 'close_handle()' function
> will have to loop through and free all nvlist members associated with
> the handle.
The error structures are in the handle. Since we're calling be_close_handle
with
the handle returned from the libbe library calls it already has them and would
therefore not need to deal with the nvlists being returned by the accessor
functions. It would be expected that the caller of these accessor functinos
would free up any memory assosiated with them.
-evan
>
> thanks
> sarah
> *****
>
> Evan Layton wrote:
>> I have updated the functional/design spec for the BE error and
>> observability project based on all of the feedback to this point.
>> I believe I have covered all of the issues and concerns raised to
>> this point.
>>
>> Please provide your comments by Thursday 8/27.
>>
>> Thanks,
>> -evan
>>
