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

[Richard Mortier <richard.mortier@xxxxxxxxxxxx>]

On 30 September 2016 at 17:13, Hannes Mehnert <hannes@xxxxxxxxxxx> 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.

Sounds good to me too!

Only thing that comes to mind is to clarify: in cases where one writes
a unikernel that can use (eg) one of two devices, is there a way to
determine which of the devices is actually available at boot, without
triggering an error?

(I'm thinking of the case of something like a router that supports N
ports where N isn't known until runtime.)

Having said that, if this isn't supported at present anyway, then it
sounds like something that might need a device interface update in
future and so shouldn't stall your suggestion.

(Or maybe the model is that you late bind N by rebuilding the
unikernel once you do know what N is?)

-- 
Richard Mortier
richard.mortier@xxxxxxxxxxxx

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