From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 856151B2CB for ; Fri, 19 Jan 2018 02:11:18 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 0BE7B20C6B; Thu, 18 Jan 2018 20:11:18 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 18 Jan 2018 20:11:18 -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=EYdskcF6yNWcMmTLoji42mvpVB 1gizOfzFjbDTcxaKw=; b=Wt8P6GWLHETZykb0wg+r4nqEJwDuVQA3f3z0n8uLEX uScuiFIshHx+dFloNU1jBBepuCdqxRfeVCcVjsRrNW18CLN7BqPUrBKpozVzdxXG fiF2OIik2/L32B7B/SBkjhH3f2NwTKmSskR3DNJzMXsagFrXV1fY+npT9wTF0ZMu E= 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=EYdskc F6yNWcMmTLoji42mvpVB1gizOfzFjbDTcxaKw=; b=awCSK+6ZA6tBKUVaEqb0Ef mKJLUkltHAY8A4CcbZPTFKNcaPq4qS46+WzOflRoFESMjXRCTXLU+vNE6jg7ti3O kao3bGMtVtc/S+EyepYyq3QS63GRA062YK5vO/kM5ydpdOdlbsv2FsZ6YgJ7dzma uWdWLpR/nCEBBTKe9Awg+S24d09gwBpAwwIrSs/iHFS5D2i/AQ7ELTDRMdLdnLgB KLzUAJfFPU2KVlzOdikImoNhCKMwn7ry3vy2rQBEWd6a/eSP0Tns7Z17OSFsKMrT mLgMdwrNboLbZeTH3pRWgNjlf6l4f882wfnyJEcBA/uf04lVkrdOoZOKkJvkCklg == 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 AB3E624608; Thu, 18 Jan 2018 20:11:17 -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, jblunck@infradead.org, shreyansh.jain@nxp.com, jingjing.wu@intel.com, helin.zhang@intel.com, motih@mellanox.com Date: Fri, 19 Jan 2018 02:10:43 +0100 Message-ID: <1774232.A2D1EWPitG@xps> In-Reply-To: <54cdd881-2482-242b-c4a3-867c28d14223@intel.com> References: <1515679534-22473-2-git-send-email-jia.guo@intel.com> <10337288.PlhJV8PepH@xps> <54cdd881-2482-242b-c4a3-867c28d14223@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH V11 1/3] eal: add uevent monitor api and callback func 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: Fri, 19 Jan 2018 01:11:18 -0000 18/01/2018 05:23, Guo, Jia: > > On 1/18/2018 5:59 AM, Thomas Monjalon wrote: > > 15/01/2018 11:48, Jeff Guo: > >> + * It registers the callback for the specific event. Multiple > >> + * callbacks cal be registered at the same time. > >> + * > >> + * @param device_name > >> + * The device name. > >> + * @param cb_fn > >> + * callback address. > >> + * @param cb_arg > >> + * address of parameter for callback. > >> + * > >> + * @return > >> + * - On success, zero. > >> + * - On failure, a negative value. > >> + */ > >> +int rte_dev_callback_register(char *device_name, rte_dev_event_cb_fn cb_fn, > >> + void *cb_arg); > > What is the device name? > > > > I think we should register a callback for a rte_device or NULL (all devices). > please see my v12 patch, the device name have been info to user. > i think a device name for a callback might be fulfill , since if use > NULL for all device, a callback could not belong to a NULL point. if > there are any advantage by callback for a rte_device, please explicit > outline it. and i think it must be a improvement and anyway if need i > will try to make it better. > and what ever a callback for a rte_device or a device name for a > callback, i think that is not our gap, i guess what you care about is > that the new and firstly hot plug in device monitor , so i would add > null check for identify these new device callback. am i right? Yes I am looking for new device event.