From: Thomas Monjalon <thomas@monjalon.net>
To: Arnon Warshavsky <arnon@qwilt.com>
Cc: anatoly.burakov@intel.com, wenzhuo.lu@intel.com,
declan.doherty@intel.com, jerin.jacob@caviumnetworks.com,
bruce.richardson@intel.com, ferruh.yigit@intel.com, dev@dpdk.org
Subject: Re: [PATCH] eal: replace rte_panic instances to return an error value
Date: Tue, 20 Mar 2018 23:04:13 +0100 [thread overview]
Message-ID: <6503395.k68LoKUDuZ@xps> (raw)
In-Reply-To: <1521581285-4709-1-git-send-email-arnon@qwilt.com>
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 :)
next prev parent reply other threads:[~2018-03-20 22:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-20 21:28 [PATCH] eal: replace rte_panic instances to return an error value Arnon Warshavsky
2018-03-20 22:04 ` Thomas Monjalon [this message]
2018-03-20 22:42 ` Arnon Warshavsky
2018-03-20 22:49 ` Thomas Monjalon
2018-03-20 23:04 ` Arnon Warshavsky
2018-03-21 8:21 ` Thomas Monjalon
2018-03-21 8:47 ` Arnon Warshavsky
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=6503395.k68LoKUDuZ@xps \
--to=thomas@monjalon.net \
--cc=anatoly.burakov@intel.com \
--cc=arnon@qwilt.com \
--cc=bruce.richardson@intel.com \
--cc=declan.doherty@intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=jerin.jacob@caviumnetworks.com \
--cc=wenzhuo.lu@intel.com \
/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.