[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MirageOS-devel] load/startup time error handling



On 09/30/2016 11:13 AM, Hannes Mehnert wrote:

Hey,

There has been lots of threads about error reporting (both on this list
and in several issues).  I want to focus in here only on _load time
errors_ - which happen during startup (exactly when `connect` is
called).  Please leave run time error handling out of this thread.

So far, connect returns [ `Ok of 'a | `Error of 'b ] Lwt.t, and in the
error case functoria emits a "fail (Failure <devicename>)".  This is
clearly not very informative to potential users (an example being
"Failure net11").

I've iterated over the potential solutions with Mindy some days ago, and
wanted to ask the broader developer community: is there any non-fatal
initialisation error you can think of?  I cannot think of any (and
couldn't find any in various libraries I looked into).  I also cannot
think of actions you'd like to do when a failure occurs during startup
(apart from fixing the code, recompiling, and restarting).

Because, if not, we can simplify this rather radically by having connect
return an 'a Lwt.t, and in case of an error (such as "permission denied"
in mirage-net-unix) fail and never transit into running state of the
unikernel.

This would also, as a side effect, simplify run time errors since the
type error would not need to be convoluted with the potential startup
errors as it is the case now.

If nobody disagrees (and comes up with non-contrived examples), I'm
happy to massage code into this direction within the next few days.

As is probably obvious from your mention above, I'm in favor of this (and have failed to come up with non-contrived examples since we last discussed). Thanks for pushing this forward. :)

-Mindy

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.