From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Wiles, Keith" Subject: Re: [RFC PATCH] eal:Add new API for parsing args at rte_eal_init time Date: Thu, 4 Jun 2015 14:51:02 +0000 Message-ID: References: <1433357393-54434-1-git-send-email-keith.wiles@intel.com> <20150603171255.545e0df8@urahara> <20150604135542.GC24585@hmsreliant.think-freely.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" To: David Marchand Return-path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 0B306C388 for ; Thu, 4 Jun 2015 16:51:04 +0200 (CEST) In-Reply-To: Content-Language: en-US Content-ID: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" From: David Marchand > Date: Thursday, June 4, 2015 at 9:43 AM To: Keith Wiles > Cc: Neil Horman >, "dev= @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 > 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