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