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