From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 744261B1D4 for ; Tue, 9 Jan 2018 14:40:26 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 226EE20ABF; Tue, 9 Jan 2018 08:40:26 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 09 Jan 2018 08:40:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=8sDXT5KSjygymCYt6WwKl1FTjG zvjrFlTdBGEZHVEsk=; b=U7up/33VnIXlAO/5Gum7Vflls//MPgb7e1chSpoYas w86QgctM38ik0p9WbEr/c7SEcN4LUqNxAlNGEMN7zCUgH9yO2LZHhaKxSQYcyBh8 7QAYMzpGGa0MLvUSVzdFvhpF9o0J/lWrCtKUM2Ja7Za5HGqksxUOQTn+W+WftFt+ A= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=8sDXT5 KSjygymCYt6WwKl1FTjGzvjrFlTdBGEZHVEsk=; b=mHzBwWPEvhLeHsQYQTPe8T Szhg9yLqq0CM7HTvdibEBbsz/Uvsin8E1C1rjiDCxlJaPEl0RRsbo1j+bhSBtMAK n5bcdQbURUPXmzg+gRdUZD2SF1Ws8egOVJ1KVm1AkcsyxTMj5/G+FiI+i/ivqi0X ePIR8E5/piz+bNlqiedahQGS8e9n2hapJHsizc+oQfC8FxwR9Ocjpeav+Cq4MpC/ zZsTKAddUUdyAILaq8bNGhpWeR1S2P1GeC2uVGeP+qhwuw77N0fV4fkR8pMb2rR3 N8L7/PaxO92GHCyNTk3IdRZtU4Cv9h4VVwRrJFafMP+kOPc4XzYwEhNipeQxnmMg == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id BC2D524599; Tue, 9 Jan 2018 08:40:25 -0500 (EST) From: Thomas Monjalon To: "Guo, Jia" Cc: dev@dpdk.org, stephen@networkplumber.org, bruce.richardson@intel.com, ferruh.yigit@intel.com, gaetan.rivet@6wind.com, konstantin.ananyev@intel.com, shreyansh.jain@nxp.com, jingjing.wu@intel.com, helin.zhang@intel.com, motih@mellanox.com, harry.van.haaren@intel.com Date: Tue, 09 Jan 2018 14:40:01 +0100 Message-ID: <4048320.sz8XtuZNvT@xps> In-Reply-To: References: <1509567405-27439-3-git-send-email-jia.guo@intel.com> <1930193.dgY3bQfKM7@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v7 1/2] eal: add uevent monitor for hot plug X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 13:40:26 -0000 > >>>> --- a/lib/librte_eal/common/include/rte_bus.h > >>>> +++ b/lib/librte_eal/common/include/rte_bus.h > >>>> /** > >>>> + * Device iterator to find a device on a bus. > >>>> + * > >>>> + * This function returns an rte_device if one of those held by the bus > >>>> + * matches the data passed as parameter. > >>>> + * > >>>> + * If the comparison function returns zero this function should stop iterating > >>>> + * over any more devices. To continue a search the device of a previous search > >>>> + * can be passed via the start parameter. > >>>> + * > >>>> + * @param cmp > >>>> + * the device name comparison function. > >>>> + * > >>>> + * @param data > >>>> + * Data to compare each device against. > >>>> + * > >>>> + * @param start > >>>> + * starting point for the iteration > >>>> + * > >>>> + * @return > >>>> + * The first device matching the data, NULL if none exists. > >>>> + */ > >>>> +typedef struct rte_device * > >>>> +(*rte_bus_find_device_by_name_t)(const struct rte_device *start, > >>>> + rte_dev_cmp_name_t cmp, > >>>> + const void *data); > >>> Why is it needed? There is already rte_bus_find_device_t. > >> because the rte_bus_find_device_t just find a device structure in the > >> device list, but here need to find a device structure by device name > >> which come from uevent info. > > I don't understand how it is different? > > Looking at the code, it is a copy/paste except it is dedicated > > to name comparison. > > You can remove rte_bus_find_device_by_name_t and provide a > > comparison function which looks at name. > i mean that if the device have been remove and then insertion, the > device have not construct when just got the device name from the uevent > massage, so this case could i use the original find device function? The device won't be in the list if it is not yet scanned. Anyway your function checks the same list. Let's stop this discussion for now and continue when the need for this function is better explained in a separate patch. You really need to introduce things one patch at a time and explain why you introduce them in the message of each patch. Thanks