Sarah Jelinek wrote:
> 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.
>
OK I've made the handle more generic and added the linked lists:
typedef struct err_info_list {
err_info_t *el_err_info;
err_info_t *next;
} err_info_list_t;
struct ei_handle {
err_info_list_t *ei_err_info; /* information for the actual
failure */
err_info_list_t *ei_cleanup_info; /* information on any needed
cleanup */
err_info_list_t *ei_fixed_err_info; /* list of errors fixed
internally */
....
};
typedef struct ei_handle be_handle_t;
typedef struct err_info err_info_t;
>
>>>
>>>> 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.
right, but I won't be exporting these 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.
>
> Ok, we could however, code in a hierarchy of data into the returned
> handle if we wanted to.
yes that should be possible.
>
> Sorry I am so late to this party :-). Thank you for taking the time to
> clarify things for me.
No problem! It's definitely best to get this right so it's not wasted code! :-)
Thanks!
-evan
