Hi Don! I'm truly sorry for my misunderstanding. :-( Thank you so much for your detailed comments!
I will update my patch! Thanks again! Best wishes, Tiwei Bie On Wed, Oct 14, 2015 at 05:54:14PM +0000, Don Provan wrote: > > > 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
