From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [RFC] Yet another option for DPDK options Date: Thu, 02 Jun 2016 15:19:37 +0200 Message-ID: <2363376.b1CWhBpcZG@xps13> References: <20160602104106.GA12923@hmsreliant.think-freely.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: "Wiles, Keith" , Yuanhan Liu , dev@dpdk.org, "Richardson, Bruce" , "Tan, Jianfeng" , Stephen Hemminger , Christian Ehrhardt , Panu Matilainen , Olivier Matz To: Neil Horman Return-path: Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id 75F1D58D4 for ; Thu, 2 Jun 2016 15:19:39 +0200 (CEST) Received: by mail-wm0-f47.google.com with SMTP id a20so67117834wma.1 for ; Thu, 02 Jun 2016 06:19:39 -0700 (PDT) In-Reply-To: <20160602104106.GA12923@hmsreliant.think-freely.org> 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" 2016-06-02 06:41, Neil Horman: > I'm not sure why you're focusing no selecting a config file format at all. Why > not just focus on removing the argument parsing from the core rte_eal_init code, > instead passing in a configuration struct that is stored and queried per > application. Leave the parsing of a config file and population of that config > struct as an exercize to the application developer. That way a given > application can use command line options, config files, or whatever method they > choose, which would be in keeping with traditional application design. > > For the purposes of the example apps, it would seem that either JSON, YAML, or > the above Lua format would work just fine. +1