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

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


  • To: Hannes Mehnert <hannes@xxxxxxxxxxx>
  • From: Anil Madhavapeddy <anil@xxxxxxxxxx>
  • Date: Sat, 1 Oct 2016 12:25:36 +0100
  • Cc: "mirageos-devel@xxxxxxxxxxxxxxxxxxxx" <mirageos-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Sat, 01 Oct 2016 11:25:42 +0000
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=recoil.org; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=EnQdFeTauMqE6vEPDkOzSSYj2gQoXrTBBlblHr5/UTAUOu+LoII 4sdMH1MSPJ2ZgrX4zfM3f+cRviogPKAKNcNWqY3asWB54ryRKvNj9VxMF6iTvWAl 95/laPLL1ynYyWixR3z3cB2oUB/c38Fc4Ghtr5dHiSlItDV4LREMnSz0=
  • List-id: Developer list for MirageOS <mirageos-devel.lists.xenproject.org>

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

 


Rackspace

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