From: David Marchand <david.marchand at 6wind.com<mailto:david.march...@6wind.com>> Date: Thursday, June 4, 2015 at 9:43 AM To: Keith Wiles <keith.wiles at intel.com<mailto:keith.wiles at intel.com>> Cc: Neil Horman <nhorman at tuxdriver.com<mailto:nhorman at tuxdriver.com>>, "dev at dpdk.org<mailto:dev at dpdk.org>" <dev at dpdk.org<mailto:dev at dpdk.org>> Subject: Re: [dpdk-dev] [RFC PATCH] eal:Add new API for parsing args at rte_eal_init time
On Thu, Jun 4, 2015 at 4:27 PM, Wiles, Keith <keith.wiles at intel.com<mailto:keith.wiles at intel.com>> wrote: Hi Neil and Stephen, I agree this is not saving instructions and adding performance, but of code clutter and providing a layered model for the developer. The rte_eal_init() routine still exists and I was not trying to remove that API only layer a convenient API for common constructs. > >Its not a bad addition, I'm just not sure its worth having to take on the >additional API surface to include. I'd be more supportive if you could >enhance >the function to allow the previously mentioned before/after flexibiilty. >Then >we could just deprecate rte_eal_init as an API call entirely, and use this >instead. I can see we can create an API to add support for doing the applications args first or after, but would that even be acceptable? What's the point ? Adding stuff just for saving lines ? Are you serious about this ? Wow, OK dropped! -- David Marchand
