[dpdk-dev] [PATCH] eal/bsd: reinitialize optind and optreset to 1

[Don Provan]

> > On Wed, Oct 14, 2015 at 10:28:44AM +0800, Tiwei Bie wrote:
> > > It is designed to have DPDK's parameters specified in the front of the
> > > cmd line and terminated by '--'.

In other words, it is designed assuming the DPDK library can dictate
the application's command line. This is an incorrect assumption
that should be eliminated.

I don't think I'm the only one that has figured out that layering a
service on top of DPDK requires creating a fake argc/argv array.
The original plan of having rte_eal_init() parse the actual application
command line organized as dictated by DPDK is not reasonable.

> > > And 1 or 0 are not some
> > > arbitrary values. They are used to put the index back to the beginning
> > > of the new argv[] array.

They're arbitrary values from the point of view of the calling
application. If the caller is using getopt() for its own purposes,
it has every reason to expect optind to have the same value
after the call to rte_eal_init() that it had before, not some
other value that the DPDK library happened to think was
useful.

> > > We shouldn't mix up DPDK's parameters and application's parameters.
> > > And we should group them using '--'.

Exactly! Yet we do confuse the two by using getopt() without considering
that the application's parameters might not be in the argc/argv list that's
passed to rte_eal_init().

> I'm considering updating optind to make it point to the option after
> '--' before eal_parse_args() returns, and eal_parse_args() will return
> 0 to avoid breaking the current applications which use the return value
> of rte_eal_init() to update argc/argv.
>
> Any comments? Thanks! :-)

Don't do it. Last time I looked, optind wasn't even mentioned in the
documentation. Even if I thought it was reasonable to change it,
I would still argue against using it as an undocumented return
value, particularly when the documented return value works fine.

-don provan
dprovan at bivio.net