[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [MirageOS-devel] load/startup time error handling
On 30 Sep 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. This sounds good to me. Having decent connect error messages is more important than attempting recovery, at least for Mirage3... Anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |