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 290BCC4E2 for ; Thu, 16 Jun 2016 12:50:42 +0200 (CEST) Received: from pcviktorin.fit.vutbr.cz (pcviktorin.fit.vutbr.cz [147.229.13.147]) by wes1-so2.wedos.net (Postfix) with ESMTPSA id 3rVgCP5cDrztK; Thu, 16 Jun 2016 12:50:41 +0200 (CEST) Date: Thu, 16 Jun 2016 12:45:36 +0200 From: Jan Viktorin To: Thomas Monjalon Cc: Shreyansh Jain , David Marchand , dev@dpdk.org, "Iremonger, Bernard" Message-ID: <20160616124536.7b6a53d3@pcviktorin.fit.vutbr.cz> In-Reply-To: <1810664.yLo38W7veq@xps13> References: <1454076516-21591-1-git-send-email-david.marchand@6wind.com> <1620661.VgMl8ZQWnK@xps13> <20160616082338.5857363.60439.5141@rehivetech.com> <1810664.yLo38W7veq@xps13> Organization: RehiveTech MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2 00/17] prepare for rte_device / rte_driver 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: Thu, 16 Jun 2016 10:50:42 -0000 On Thu, 16 Jun 2016 11:19:59 +0200 Thomas Monjalon wrote: > 2016-06-16 10:23, Jan Viktorin: > > I think, we should consider to move it to somebody else. I would work on it, however, I don't see all the tasks that are to be done. That's why I was waiting to finalize those patchs by David or Thomas. For me, the important things were to generalize certain things to remove dependency on PCI. This is mostly done (otherwise the SoC patchset couldn't be done in the way I've posted it). > > > > Now, there is some pending work to remove pmd_type. Next, to find out some generalization of rte_pci_device/driver to create rte_device/driver (I've posted several suggestions in the 0000 of SoC patchset). For the pmd_type removal, I am not very sure about the original David's intentions. What should be the result? Should there be a special struct rte_virt_device or something like that? > > > > What more? > > We need a clean devargs API in EAL, not directly related to hotplug. > Then the hotplug can benefit of the devargs API as any other device config. Do we have some requirements for this? Would it be a complete redefinition of the API? I don't see the relations to hotplug. > > The EAL resources (also called devices) need an unique naming convention. > No idea about this. What do you mean by the unique naming convention? Jan