All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Arnon Warshavsky <arnon@qwilt.com>
Cc: dev@dpdk.org, anatoly.burakov@intel.com, wenzhuo.lu@intel.com,
	declan.doherty@intel.com, jerin.jacob@caviumnetworks.com,
	bruce.richardson@intel.com, ferruh.yigit@intel.com,
	ranjit.menon@intel.com, anand.rawat@intel.com,
	Pallavi Kadam <pallavi.kadam@intel.com>,
	Harini Ramakrishnan <harini.ramakrishnan@microsoft.com>,
	"O'Hare, Cathal" <cathal.ohare@intel.com>
Subject: Re: [dpdk-dev] [PATCH v6 00/11] al: replace calls to rte_panic and refrain from new instances
Date: Thu, 18 Apr 2019 16:50:48 +0200	[thread overview]
Message-ID: <3131803.2ETXjPmY0d@xps> (raw)
In-Reply-To: <1524552123-31378-1-git-send-email-arnon@qwilt.com>

Hi,

24/04/2018 08:41, Arnon Warshavsky:
> The purpose of this patch series 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.
> 
> This patch modifies the majority of rte_panic calls
> under lib and drivers, and replaces them with a log message
> and an error return code according to context,
> that can be propagated up the call stack.
> 
> - 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..
> - local void functions with no api were changed to retrun a value
>   where needed
> - No change took place in example and test files
> - No change took place for debug assertions calling panic
> - A new function was added to devtools/checkpatches.sh
>   in order to prevent new additions of calls to rte_panic
>   under lib and drivers.
> 
> Keep calm and don't panic

What happened to this patchset?

This is definitely an improvement. We must remove rte_panic from libs.
Arnon, are you still available to rebase this patchset in preparation
of 19.08? Or someone else?

What are the required API breakages? I see one in ethdev which requires
a deprecation notice to be sent for publishing in 19.05.

Is there more rte_panic to remove?



  parent reply	other threads:[~2019-04-18 14:50 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-24  6:41 [PATCH v6 00/11] al: replace calls to rte_panic and refrain from new instances Arnon Warshavsky
2018-04-24  6:41 ` [PATCH v6 01/11] crypto/dpaa: replace rte_panic instances in crypto/dpaa driver Arnon Warshavsky
2018-04-24 15:00   ` Stephen Hemminger
2018-04-24 19:27     ` Arnon Warshavsky
2018-04-24  6:41 ` [PATCH v6 02/11] bond: replace rte_panic instances in bonding driver Arnon Warshavsky
2018-04-24  6:41 ` [PATCH v6 03/11] e1000: replace rte_panic instances in e1000 driver Arnon Warshavsky
2018-04-24  6:41 ` [PATCH v6 04/11] ixgbe: replace rte_panic instances in ixgbe driver Arnon Warshavsky
2018-04-24  6:41 ` [PATCH v6 05/11] eal: replace rte_panic instances in eventdev Arnon Warshavsky
2018-04-24 15:04   ` Stephen Hemminger
2018-04-24 15:06   ` Stephen Hemminger
2018-04-24 19:28     ` Arnon Warshavsky
2018-04-24  6:41 ` [PATCH v6 06/11] kni: replace rte_panic instances in kni Arnon Warshavsky
2018-04-24  6:41 ` [PATCH v6 07/11] eal: replace rte_panic instances in hugepage_info Arnon Warshavsky
2018-04-24  6:42 ` [PATCH v6 08/11] eal: replace rte_panic instances in interrupts thread Arnon Warshavsky
2018-04-24  6:42 ` [PATCH v6 09/11] eal: replace rte_panic instances in ethdev Arnon Warshavsky
2018-04-24  6:42 ` [PATCH v6 10/11] eal: replace rte_panic instances in init sequence Arnon Warshavsky
2018-04-24  6:42 ` [PATCH v6 11/11] devtools: prevent new instances of rte_panic and rte_exit Arnon Warshavsky
2018-04-24  6:44 ` [PATCH v6 00/11] al: replace calls to rte_panic and refrain from new instances Arnon Warshavsky
2018-04-24  6:57   ` Arnon Warshavsky
2019-04-18 14:50 ` Thomas Monjalon [this message]
2019-04-21 19:16   ` [dpdk-dev] " Arnon Warshavsky
2019-04-21 21:10     ` Thomas Monjalon
2019-05-08 11:15 ` Thomas Monjalon
2019-05-08 14:47   ` David Marchand
2019-05-09 12:05   ` Burakov, Anatoly
2019-05-09 13:16     ` Thomas Monjalon
2019-05-23 11:14       ` Thomas Monjalon
2019-05-23 13:13         ` 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=3131803.2ETXjPmY0d@xps \
    --to=thomas@monjalon.net \
    --cc=anand.rawat@intel.com \
    --cc=anatoly.burakov@intel.com \
    --cc=arnon@qwilt.com \
    --cc=bruce.richardson@intel.com \
    --cc=cathal.ohare@intel.com \
    --cc=declan.doherty@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=harini.ramakrishnan@microsoft.com \
    --cc=jerin.jacob@caviumnetworks.com \
    --cc=pallavi.kadam@intel.com \
    --cc=ranjit.menon@intel.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.