Re: [dpdk-dev] [PATCH v3 00/25] linux/eal: Remove most causes of panic on init

[Stephen Hemminger <stephen@networkplumber.org>]

On Thu,  9 Feb 2017 09:29:28 -0500
Aaron Conole <aconole@redhat.com> wrote:

> 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).
> 
> Changes ->v2:
> - Audited all "RTE_LOG (" calls that were introduced, and converted
>   to "RTE_LOG("
> - Added some fprintf(stderr, "") lines to indicate errors before logging
>   is initialized
> - Removed assignments to errno.
> - Changed patch 14/25 to reflect EFAULT, and document in 25/25
> 
> Changes ->v3:
> - Checkpatch issues in patches 3 (spelling mistake), 9 (issue with leading
>   spaces), and 19 (braces around single line statement if-condition)
> 
> I kept the rte_errno reflection, since this is control-path code and the
> init function returns a sentinel value of -1.
> 
> Aaron Conole (25):
>   eal: CPU init will no longer panic
>   eal: return error instead of panic for cpu init
>   eal: No panic on hugepages info init
>   eal: do not panic on failed hugepage query
>   eal: failure to parse args returns error
>   eal-common: introduce a way to query cpu support
>   eal: Signal error when CPU isn't supported
>   eal: do not panic on memzone initialization fails
>   eal: set errno when exiting for already called
>   eal: Do not panic on log failures
>   eal: Do not panic on pci-probe
>   eal: do not panic on vfio failure
>   eal: do not panic on memory init
>   eal: do not panic on tailq init
>   eal: do not panic on alarm init
>   eal: convert timer_init not to call panic
>   eal: change the private pipe call to reflect errno
>   eal: Do not panic on interrupt thread init
>   eal: do not error if plugins fail to init
>   eal_pci: Continue probing even on failures
>   eal: do not panic on failed PCI probe
>   eal_common_dev: continue initializing vdevs
>   eal: do not panic (or abort) if vdev init fails
>   eal: do not panic when bus probe fails
>   rte_eal_init: add info about rte_errno codes
> 
>  lib/librte_eal/common/eal_common_cpuflags.c        |  13 ++-
>  lib/librte_eal/common/eal_common_dev.c             |   5 +-
>  lib/librte_eal/common/eal_common_lcore.c           |   7 +-
>  lib/librte_eal/common/eal_common_pci.c             |  15 ++-
>  lib/librte_eal/common/eal_common_tailqs.c          |   3 +-
>  .../common/include/generic/rte_cpuflags.h          |   9 ++
>  lib/librte_eal/common/include/rte_eal.h            |  27 ++++-
>  lib/librte_eal/linuxapp/eal/eal.c                  | 122 +++++++++++++++------
>  lib/librte_eal/linuxapp/eal/eal_hugepage_info.c    |   6 +-
>  lib/librte_eal/linuxapp/eal/eal_interrupts.c       |   5 +-
>  10 files changed, 161 insertions(+), 51 deletions(-)
> 

I worry that some of these early failure messages may never be visible
because the logging system has not been initialized. Might be safer to
just use fprintf(stderr, ...) or define a new wrapper function.