[RFC] Classify and remove (some) abort()s in libxl

[Wei Liu <wei.liu2@citrix.com>]

Hi all

There has been some interest in removing abort() in libxl in another
thread. I think this topic deserves a dedicated thread.

I've checked most instances of abort() and exit() in code and classify
them as several classes.

* System has entered an impossible to recover state

Can't be removed, there is no meaningful return code to return.

E.g. libxl_utils.c, libxl_event.c, libxl_exec.c and libxl_fork.c

* Used by some stub functions

Can be classified as "impossible to recover state" because caller
shouldn't have use them in the first place. But can be relaxed to
return error code.

* Configuration error

Some internal functions expect sanitised input. Up until now the
expectation (at least AIUI) is that libxl should have sanitised those
values before calling internal functions. I'm not sure if this rule is
strictly followed though.

The abort() in this class can be and turn into error return path.

E.g. various devices and domain configuration options

* Memory allocation failure

Actually exit() is called, but process will exit anyway.  Can't be
easily changed without rewriting error handle logic across libxl.


The "configuration error" class is the easiest one to trip over for
library user. I think we can change that class to return error code
provided there is enough interest.

The "stub functions" class can also be dealt with, but I'm not too keen
on changing that.


Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel