From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wes1-so2.wedos.net (wes1-so2.wedos.net [46.28.106.16]) by dpdk.org (Postfix) with ESMTP id 9FE8D5A58 for ; Sun, 3 Jan 2016 18:12:49 +0100 (CET) Received: from jvn (dynamic-109-81-211-152.ipv4.broadband.iol.cz [109.81.211.152]) by wes1-so2.wedos.net (Postfix) with ESMTPSA id 3pYRVS5bZjz4xc; Sun, 3 Jan 2016 18:12:48 +0100 (CET) Date: Sun, 3 Jan 2016 18:12:43 +0100 From: Jan Viktorin To: Stephen Hemminger Message-ID: <20160103181243.69d19526@jvn> In-Reply-To: <20160102194540.1f04ce7d@jvn> References: <1451682326-5834-1-git-send-email-viktorin@rehivetech.com> <1451682326-5834-2-git-send-email-viktorin@rehivetech.com> <20160102100144.5e87e98b@xeon-e3> <20160102194540.1f04ce7d@jvn> Organization: RehiveTech X-Mailer: Claws Mail 3.13.0 (GTK+ 2.24.28; x86_64-unknown-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [RFC 1/7] eal/common: define rte_soc_* related common interface X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2016 17:12:49 -0000 On Sat, 2 Jan 2016 19:45:40 +0100 Jan Viktorin wrote: > > > > Do you consider this will break binary compatibility since > > sizeof (rte_soc_addr) is PATH_MAX (1024) and the other elements of the > > union inside rte_devargs are much smaller (like 32 bytes). > > > > I had a bad feeling about this... Originally, I started with a pointer > 'const char *' so it can be done that way... However, this brings > compilator mad as it does not allow to cast char * -> const char * > because of the strict DPDK compilation settings. I didn't find any > workaround yet. I think I can make it just 'char *' for the next version > of the patch set. Having rte_devargs to contain only char * instead of char[PATH_MAX] brings an issue. There is no common devargs_free function. Inside the function rte_eal_devargs_add, I must malloc memory here to fill the devtree_path. But there is no general way to free it. At least, I didn't find such code... I need to do this: 108 case RTE_DEVTYPE_WHITELISTED_SOC: 109 case RTE_DEVTYPE_BLACKLISTED_SOC: 110 devargs->soc.addr.devtree_path = strdup(buf); because the buf variable is deallocated at the end of the function. In fact, I do not clearly understand the rte_eal_devargs_add function. What is the expected input? The call to rte_eal_parse_devargs_str separates the string into drvname and drvargs. What are the drvargs supposted to be? I'd expect the user types -w or -b (for PCI is the quaternion, for SoC it's the device-tree path). Regards Jan -- Jan Viktorin E-mail: Viktorin@RehiveTech.com System Architect Web: www.RehiveTech.com RehiveTech Brno, Czech Republic