On 07-Mar-18 9:59 AM, Thomas Monjalon wrote:
07/03/2018 10:05, Burakov, Anatoly:
On 07-Mar-18 8:32 AM, Thomas Monjalon wrote:
Hi,
06/03/2018 19:28, Arnon Warshavsky:
The use case addressed here is dpdk environment init
aborting the process due to panic,
preventing the calling process from running its own tear-down actions.
Thank you for working on this long standing issue.
A preferred, though ABI breaking solution would be
to have the environment init always return a value
rather than abort upon distress.
Yes, it is the preferred solution.
We should not use exit (panic & co) inside a library.
It is important enough to break the API.
+1, panic exists mostly for historical reasons AFAIK. it's a pity i
didn't think of it at the time of submitting the memory hotplug RFC,
because i now hit the same issue with the v1 - we might panic while
holding a lock, and didn't realize that it was an API break to change
this behavior.
Can this really go into current release without deprecation notices?
If such an exception is done, it must be approved by the technical board.
We need to check few criterias:
- which functions need to be changed
- how the application is impacted
- what is the urgency
If a panic is removed and the application is not already checking some
error code, the execution will continue without considering the error.
Some rte_panic could be probably removed without any impact on applications.
Some rte_panic could wait for 18.08 with a notice in 18.05.
If some rte_panic cannot wait, it must be discussed specifically.
Can we add a compile warning for adding new rte_panic's into code? It's
a nice tool while debugging, but it probably shouldn't be in any new
production code.
--
Thanks,
Anatoly
