Hi Evan,
Evan Layton wrote:
> 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.
We could make this general purpose, that is, make it all linked lists(as
we talked about on the phone earlier) so that this handle definition is
useful to the greater Caiman audience.
>>
>>> 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.
Now that I understand better the BE specific things about this, that is
the error codes/string definitions for it makes sense.
As we talked about, it might be possible to define a general purpose
library and a set of interfaces which call into more specific interfaces
such at the BE ones you define above.
>>
>> 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.
Ok, we could however, code in a hierarchy of data into the returned
handle if we wanted to.
Sorry I am so late to this party :-). Thank you for taking the time to
clarify things for me.
sarah
