09/05/2019 14:05, Burakov, Anatoly: > 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?
Yes I think we can keep them. In order to make it clear, we could replace them with RTE_ASSERT or RTE_VERIFY (which calls rte_panic).
