07/03/2018 17:31, Arnon Warshavsky:
> > > 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.
> >
> > Yes could be nice to automatically detect it in drivers/ or lib/
> > d
> > 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.
>
> Yes could be nice to automatically detect it in drivers/ or lib/
> directories.
>
How do we apply a warning only to new
> > maybe we should keep the callback patch until all the remains are gone.
>
> Why introducing a new API for a temporary solution?
> It has always been like that, so the remaining occurences could wait
> one more release, isn't it?
>
> Yes.
I guess I am over excited to get rid of my local changes
07/03/2018 14:23, Arnon Warshavsky:
> >
> > 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.
Yes could be nice to automatically detect it in drivers/ or lib/ directories.
> I thou
07/03/2018 12:02, Arnon Warshavsky:
> > > 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
>
> 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.
>
I thought about renaming the current function and calls to something like
deprecated_rte_panic()
, and keep the old API with __rte
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 run
> > 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
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-dow
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
>
>
> Are you OK to visit the other side of the solution?
>
>
Sure. If no one is emotionally attached to those panic aborts,
this patch can be discarded and I will create a new one with the license to
break.
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 solut
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.
A preferred, though ABI breaking solution would be
to have the environment init always return a value
rather than abort upon distress.
This
13 matches
Mail list logo
