All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: dev@dpdk.org
Subject: Re: [24.03 RFC 0/3] Add argument manipulation library
Date: Thu, 2 Nov 2023 10:50:29 -0700	[thread overview]
Message-ID: <20231102105029.2c9eff43@fedora> (raw)
In-Reply-To: <20231102172849.7400-1-bruce.richardson@intel.com>

On Thu,  2 Nov 2023 17:28:46 +0000
Bruce Richardson <bruce.richardson@intel.com> wrote:

> DPDK has traditionally assumed that apps are written where argc/argv
> parameters are passed directly to rte_eal_init() and then app arguments
> are handled afterwards, as is done in the DPDK apps and examples.
> 
> However, based on other projects, like VPP and OVS, we know that this is
> often not the case. Instead, the apps build up argument lists internally
> themselves and pass those to the init function, and DPDK never directly
> accesses the real argc/argv values.
> 
> Therefore, let's make this mode of operation a little easier to use, by
> adding in an args library to allow an app to dynamically build up an
> args array and then pass that to EAL init. This library allows things
> like, for example, initializing a list from argv and then checking if a
> particular parameter is present, adding it if not. All the basics of
> such a library are included in patch 1, and I've found it of use myself
> when writing some simple apps internally using DPDK.
> 
> Patches 2 and 3 go a little further than this, and allow for a slightly
> different use-case, that where an app may want to allow mixing of EAL
> arguments in with app args. These patches allow the user to query if a
> particular argument is an EAL arg or not, or a valid app argument. The
> idea here would be, that an app could go through it's argument list,
> building up an argument list for EAL init by just picking out the EAL
> arguments from a full argument list. I'm less convinced of the value of
> this compared to the basics in patch 1, but I think the idea is
> interesting so seeking feedback on it.
> 
> Bruce Richardson (3):
>   args: new library to allow easier manipulation of cmdline args
>   eal: allow export of the cmdline argument parsing options
>   args: add functions to check parameter validity
> 
>  doc/api/doxy-api-index.md           |   1 +
>  doc/api/doxy-api.conf.in            |   1 +
>  lib/args/args.c                     | 301 ++++++++++++++++++++++++++++
>  lib/args/meson.build                |   5 +
>  lib/args/rte_args.h                 | 255 +++++++++++++++++++++++
>  lib/args/version.map                |  22 ++
>  lib/eal/common/eal_common_options.c |   9 +
>  lib/eal/include/rte_eal.h           |  14 ++
>  lib/eal/version.map                 |   1 +
>  lib/meson.build                     |   2 +
>  10 files changed, 611 insertions(+)
>  create mode 100644 lib/args/args.c
>  create mode 100644 lib/args/meson.build
>  create mode 100644 lib/args/rte_args.h
>  create mode 100644 lib/args/version.map
> 
> --
> 2.39.2
> 

It would be good to change rte_eal_init() from:
int rte_eal_init(int argc, char **argv);

to
int rte_eal_init(int argc, char * const *argv);

I.e it should not modify the argv's passed.
This would save unnecessary copy in applications that build synthetic args.
Example already exists in dumpcap.


  parent reply	other threads:[~2023-11-02 17:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-02 17:28 [24.03 RFC 0/3] Add argument manipulation library Bruce Richardson
2023-11-02 17:28 ` [24.03 RFC 1/3] args: new library to allow easier manipulation of cmdline args Bruce Richardson
2024-01-24 12:03   ` Thomas Monjalon
2024-01-24 13:57     ` Honnappa Nagarahalli
2023-11-02 17:28 ` [24.03 RFC 2/3] eal: allow export of the cmdline argument parsing options Bruce Richardson
2023-11-02 17:28 ` [24.03 RFC 3/3] args: add functions to check parameter validity Bruce Richardson
2024-01-24 11:53   ` Thomas Monjalon
2023-11-02 17:50 ` Stephen Hemminger [this message]
2023-11-02 18:12   ` [24.03 RFC 0/3] Add argument manipulation library Bruce Richardson

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=20231102105029.2c9eff43@fedora \
    --to=stephen@networkplumber.org \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    /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.