[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [RFC] Classify and remove (some) abort()s in libxl
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@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |