All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aaron Conole <aconole@redhat.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: dev@dpdk.org
Subject: Re: [RFC 00/23] Refactor eal_init to remove panic() calls
Date: Wed, 25 Jan 2017 16:33:41 -0500	[thread overview]
Message-ID: <f7t1svqn7t6.fsf@redhat.com> (raw)
In-Reply-To: <1909688.GKiQWP6byZ@xps13> (Thomas Monjalon's message of "Mon, 02 Jan 2017 15:22:40 +0100")

Thomas Monjalon <thomas.monjalon@6wind.com> writes:

> Hi Aaron,
>
> 2016-12-30 10:25, Aaron Conole:
>> In many cases, it's enough to simply let the application know that the
>> call to initialize DPDK has failed.  A complete halt can then be
>> decided by the application based on error returned (and the app could
>> even attempt a possible re-attempt after some corrective action by the
>> user or application).
>> 
>> There is still some work left in this series.
>
> Thanks for starting the work.
> I think it is candidate for 17.05 and can be promoted in the roadmap:
> 	http://dpdk.org/dev/roadmap
>
> Have you checked wether these changes are modifying the API?

Looks like no API changes occur with this series.

> Some doxygen comments may need to be updated when a new error code
> is used.

I haven't seen any instances, but if you'd like I can add that to the
series as some of the error values for rte_eal_init().

-Aaron

      parent reply	other threads:[~2017-01-25 21:33 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-30 15:25 [RFC 00/23] Refactor eal_init to remove panic() calls Aaron Conole
2016-12-30 15:25 ` [RFC 01/23] eal: CPU init will no longer panic Aaron Conole
2016-12-30 15:25 ` [RFC 02/23] eal: return error instead of panic for cpu init Aaron Conole
2016-12-30 15:26 ` [RFC 03/23] eal: No panic on hugepages info init Aaron Conole
2016-12-30 15:26 ` [RFC 04/23] eal: do not panic on failed hugepage query Aaron Conole
2016-12-30 15:26 ` [RFC 05/23] eal: failure to parse args returns error Aaron Conole
2016-12-30 15:26 ` [RFC 06/23] eal-common: introduce a way to query cpu support Aaron Conole
2016-12-30 15:26 ` [RFC 07/23] eal: Signal error when CPU isn't supported Aaron Conole
2016-12-30 15:26 ` [RFC 08/23] eal: do not panic on memzone initialization fails Aaron Conole
2016-12-30 15:26 ` [RFC 09/23] eal: set errno when exiting for already called Aaron Conole
2016-12-30 15:26 ` [RFC 10/23] eal: Do not panic on log failures Aaron Conole
2016-12-30 15:26 ` [RFC 11/23] eal: Do not panic on pci-probe Aaron Conole
2016-12-30 15:26 ` [RFC 12/23] eal: do not panic on vfio failure Aaron Conole
2016-12-30 15:26 ` [RFC 13/23] eal: do not panic on memory init Aaron Conole
2016-12-30 15:26 ` [RFC 14/23] eal: do not panic on tailq init Aaron Conole
2016-12-30 15:26 ` [RFC 15/23] eal: do not panic on alarm init Aaron Conole
2016-12-30 15:26 ` [RFC 16/23] eal: convert timer_init not to call panic Aaron Conole
2016-12-30 15:26 ` [RFC 17/23] eal: change the private pipe call to reflect errno Aaron Conole
2016-12-30 15:26 ` [RFC 18/23] eal: Do not panic on interrupt thread init Aaron Conole
2016-12-30 15:26 ` [RFC 19/23] eal: do not error if plugins fail to init Aaron Conole
2016-12-30 15:26 ` [RFC 20/23] eal_pci: Continue probing even on failures Aaron Conole
2016-12-30 15:26 ` [RFC 21/23] eal: do not panic on failed PCI probe Aaron Conole
2016-12-30 15:26 ` [RFC 22/23] eal_common_dev: continue initializing vdevs Aaron Conole
2016-12-30 15:26 ` [RFC 23/23] eal: do not panic (or abort) if vdev init fails Aaron Conole
2017-01-02 14:22 ` [RFC 00/23] Refactor eal_init to remove panic() calls Thomas Monjalon
2017-01-03 16:06   ` Aaron Conole
2017-01-25 21:33   ` Aaron Conole [this message]

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=f7t1svqn7t6.fsf@redhat.com \
    --to=aconole@redhat.com \
    --cc=dev@dpdk.org \
    --cc=thomas.monjalon@6wind.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.