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
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
