From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>,
Arnon Warshavsky <arnon@qwilt.com>
Cc: bruce.richardson@intel.com, dev@dpdk.org
Subject: Re: [PATCH] eal: register rte_panic user callback
Date: Wed, 7 Mar 2018 09:05:51 +0000 [thread overview]
Message-ID: <d0ef31ce-8bb3-37fb-e61e-a26b49ef3f7f@intel.com> (raw)
In-Reply-To: <304114136.g7uiPYdxRp@xps>
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?
--
Thanks,
Anatoly
next prev parent reply other threads:[~2018-03-07 9:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-06 18:28 [PATCH] eal: register rte_panic user callback Arnon Warshavsky
2018-03-07 8:32 ` Thomas Monjalon
2018-03-07 8:57 ` Arnon Warshavsky
2018-03-07 9:05 ` Burakov, Anatoly [this message]
2018-03-07 9:59 ` Thomas Monjalon
2018-03-07 11:02 ` Arnon Warshavsky
2018-03-07 15:04 ` Thomas Monjalon
2018-03-07 16:26 ` Arnon Warshavsky
2018-03-07 11:29 ` Burakov, Anatoly
2018-03-07 13:23 ` Arnon Warshavsky
2018-03-07 15:06 ` Thomas Monjalon
2018-03-07 16:31 ` Arnon Warshavsky
2018-03-07 17:17 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d0ef31ce-8bb3-37fb-e61e-a26b49ef3f7f@intel.com \
--to=anatoly.burakov@intel.com \
--cc=arnon@qwilt.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.