[dpdk-dev] [PATCH] eal: replace rte_panic instances to return an error value

[Thomas Monjalon]

Hi,

20/03/2018 22:28, Arnon Warshavsky:
> The purpose of this patch 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.

Thanks for working on this important topic.

> This patch modifies the majority of rte_panic calls under lib and drivers,
> and replaces them with a new variation of rte_panic macro
> that does not abort and returns an error value
> that can be propagated up the call stack.

My feeling is that we could replace most of them by a log + return.
I did not think you would add a new macro. Why you chose this way?

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

Yes, better to let driver maintainers decide if you are not sure.

>   I would like to define a device health state that can be monitored from
>   the side,and this will be an independant patch.

You mean when a device become unusable?

> - No change took place in example and test files

Yes, panic/exit is allowed in applications.

> - No change took place for debug assertions calling panic

Yes, debug assert is a special case.

> - Some previously panicing void functions where changed to return a value,
>   with callers modified accordingly.

If the function is exposed to the application, I think it is an ABI change
and should follow the deprecation process.

> An additional independant patch to devtools/checkpatches.sh
> will be submitted in order to prevent new additions of calls to rte_panic
> under lib and drivers.

Yes please! +1 for an automatic check.

> Keep calm and don't panic.

Sure :)