Re: [MirageOS-devel] Error handling in Mirage

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

Yes, every interface will expose a `with sexp` representation to permit it to 
be converted into a stable serialized form.

-anil

On 10 Jul 2014, at 15:39, Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx> 
wrote:

> Would it make sense to enforce that there's a pretty printer or sexp 
> representation or something for those abstract types, in the interests of 
> debuggability? That would deal with the abstract type of id etc. Wouldn't it?
> 
> --  
> Cheers,
> 
> R.
> 
> 
> 
>> On 10 Jul 2014, at 15:34, "Anil Madhavapeddy" <anil@xxxxxxxxxx> wrote:
>> 
>>> On 10 Jul 2014, at 14:13, David Scott <scott.dj@xxxxxxxxx> wrote:
>>> 
>>> This sounds sensible to me.
>>> 
>>> When debugging one of these fatal errors (e.g. 'Disconnected' which means: 
>>> someone called 'disconnect' and then tried 'read' or 'write' afterwards) it 
>>> would be useful to have more context. For example it would probably be good 
>>> to add the device id to the exception so we know which disk it relates to. 
>>> This could help us infer that the buggy code is in the FS driver running on 
>>> disk 2 and not the irmin backend on disk 1. There might be other useful 
>>> context which is more implementation-specific. We could either just log 
>>> this to the console or we could encode it up as an Sexp.t and attach that 
>>> to the exception too?
>> 
>> We need to be a little careful with adding the device `id` into the 
>> exception, as it's abstract in the module type and can vary by device.  But 
>> I guess this is moot with exceptions -- if you're specifically catching and 
>> deconstructing it, you know the type of id since you caught it outside of a 
>> _.
>> 
>>> Since our top-level function is in the auto generated code:
>>> 
>>> let () =
>>> OS.Main.run (join [t1 ()])
>>> 
>>> For every exception we declare in our interface, should we pre-create a 
>>> default exception handler which pretty-prints it? This could also explain 
>>> to the unlucky user that this is a bug and should be reported on the issue 
>>> tracker?
>> 
>> It would be nice if every `job` that was registered would act as a monitor 
>> for its top-level exceptions.  An exception leaking up to one job shouldn't 
>> kill another one even if they're running in the same unikernel.
>> 
>> 
>>> BTW I've now forked the V1 interfaces into a V2, so feel free to propose 
>>> concrete changes as pull requests!
>> 
>> Excellent!
>> 
>> -anil
>> 
>> 
>> _______________________________________________
>> MirageOS-devel mailing list
>> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
> This message and any attachment are intended solely for the addressee and may 
> contain confidential information. If you have received this message in error, 
> please send it back to me, and immediately delete it.   Please do not use, 
> copy or disclose the information contained in this message or in any 
> attachment.  Any views or opinions expressed by the author of this email do 
> not necessarily reflect the views of the University of Nottingham.
> 
> This message has been checked for viruses but the contents of an attachment
> may still contain software viruses which could damage your computer system, 
> you are advised to perform your own checks. Email communications with the 
> University of Nottingham may be monitored as permitted by UK legislation.
> 
> 
> 
> 
> 
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
> 


_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel