On 08-May-19 12:15 PM, Thomas Monjalon wrote:
24/04/2018 08:41, Arnon Warshavsky:
The purpose of this patch series is to cleanup the library code
from paths that end up aborting the process,
and move to checking error values, in order to allow the running process
perform an orderly teardown or other mitigation of the event.
This patch modifies the majority of rte_panic calls
under lib and drivers, and replaces them with a log message
and an error return code according to context,
that can be propagated up the call stack.
- Focus was given to the dpdk initialization path
- Some of the panic calls within drivers were left in place where
the call is from within an interrupt or calls that are
on the data path,where there is no simple applicative
route to propagate the error to temination.
These should be handled by the driver maintainers..
- local void functions with no api were changed to retrun a value
where needed
- No change took place in example and test files
- No change took place for debug assertions calling panic
I did a status of rte_panic/rte_exit calls in libs.
There are a lot of cleanups to do in EAL.
We may apply the same kind of solution for Linux, FreeBSD and Windows.
The status is described below in a kind of call tree:
<snip>
librte_mempool:
void rte_mempool_*
RTE_LIBRTE_MEMPOOL_DEBUG
rte_panic
(and other similar places)
Could an argument not be made that when debugging options are enabled,
having rte_panic there is actually useful?
--
Thanks,
Anatoly
