Re: [dpdk-dev] [PATCH v6 00/11] al: replace calls to rte_panic and refrain from new instances

[Thomas Monjalon <thomas@monjalon.net>]

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).