>> >> [2] It is mentioned that the error structure will contain at least >> following information: >> * failure type >> * failure ID (error number) >> * where the failure happened >> * what went wrong >> * how to fix it (if possible) or report it >> >> How this information will map to the proposed err_info and err_data >> structures ? >> >> [3] To be honest, I don't quite understand how the error service >> will be plugged into the overall infrastructure - how the process and >> data flow will look like - I think it might be useful to provide >> some kind of 'case study' or example - e.g. how libbe is going to >> consume it in particular failure scenario. >> > > I think what may be helpful here in addition to an example from libbe or > AI would be a drawing that shows how all this fits together. I'll create > this and attach it to the design as well as adding a couple of examples. > I think for examples it might be best to add one for libbe as well as > one for AI. >
In an attempt to address these two issues, I've created some images that show what the structures might look like as well as written up a very brief example of what some of the calls _might_ look like for setting and getting error data. -evan -------------- next part -------------- A non-text attachment was scrubbed... Name: CUD-err-drawing.pdf Type: application/pdf Size: 23855 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/caiman-discuss/attachments/20090921/28fd4454/attachment.pdf> -------------- next part -------------- A non-text attachment was scrubbed... Name: CUD error usage examples.rtf Type: application/rtf Size: 1629 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/caiman-discuss/attachments/20090921/28fd4454/attachment.rtf>
