DPDK patches and discussions
 help / color / mirror / Atom feed
From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
To: "thomas@monjalon.net" <thomas@monjalon.net>,
	Bruce Richardson <bruce.richardson@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, nd <nd@arm.com>, nd <nd@arm.com>
Subject: RE: [24.03 RFC 1/3] args: new library to allow easier manipulation of cmdline args
Date: Wed, 24 Jan 2024 13:57:19 +0000	[thread overview]
Message-ID: <DBAPR08MB58145C96E0B2FE5CF06B13C2987B2@DBAPR08MB5814.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <2007834.8hb0ThOEGa@thomas>

<snip>

> 
> 02/11/2023 18:28, Bruce Richardson:
> > Add a new small library to make it easier for apps to work with
> > cmdline arguments and build up args to use when initializing EAL.
> >
> > This library is optional, and can be disabled at build time using the
> > disable libraries meson option.
> 
> This is an optional helper, so why not.
> 
> Another help for applications would be to allow initializing DPDK without the
> need of passing or building argc/argv arguments.
> I think we could add new functions rte_eal_init_*().
> Example:
> 	rte_eal_init_prepare()
> 	rte_eal_init_memory(memory parameters)
> 	rte_eal_init_devices(devargs)
> 	rte_eal_init_threads()
> 
> It should be possible to rebuild rte_eal_init() using above smaller functions to
> keep the big old rte_eal_init with argc/argv for compatibility.
We have to ensure these new APIs and argc/argv are in sync in future changes. For ex: if we add a new parameter to the API, we need a new argv. This is not a problem, but we have to do this manually.

> 


  reply	other threads:[~2024-01-24 13:57 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 [this message]
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 ` [24.03 RFC 0/3] Add argument manipulation library Stephen Hemminger
2023-11-02 18:12   ` 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=DBAPR08MB58145C96E0B2FE5CF06B13C2987B2@DBAPR08MB5814.eurprd08.prod.outlook.com \
    --to=honnappa.nagarahalli@arm.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=nd@arm.com \
    --cc=thomas@monjalon.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).