From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [PATCH V4 1/9] bus: introduce hotplug failure handler
Date: Wed, 04 Jul 2018 09:55:15 +0200
Message-ID: <2407710.IcmoihaDi7@xps>
References: <1498711073-42917-1-git-send-email-jia.guo@intel.com>
 <6033435.uqaPCSQc1q@xps> <a22aa4ea-c058-559e-8cf3-dc758e0034e5@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: dev@dpdk.org, stephen@networkplumber.org, bruce.richardson@intel.com,
 ferruh.yigit@intel.com, konstantin.ananyev@intel.com, gaetan.rivet@6wind.com,
 jingjing.wu@intel.com, motih@mellanox.com, matan@mellanox.com,
 harry.van.haaren@intel.com, qi.z.zhang@intel.com, shaopeng.he@intel.com,
 bernard.iremonger@intel.com, jblunck@infradead.org, shreyansh.jain@nxp.com,
 helin.zhang@intel.com
To: "Guo, Jia" <jia.guo@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com
 [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 62E811B04D
 for <dev@dpdk.org>; Wed,  4 Jul 2018 09:55:19 +0200 (CEST)
In-Reply-To: <a22aa4ea-c058-559e-8cf3-dc758e0034e5@intel.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

04/07/2018 09:16, Guo, Jia:
> 
> On 7/4/2018 6:21 AM, Thomas Monjalon wrote:
> > 29/06/2018 12:30, Jeff Guo:
> >>   /**
> >> + * Implementation a specific hot plug handler, which is responsible
> >> + * for handle the failure when hot remove the device, guaranty the system
> >> + * would not crash in the case.
> >> + * @param dev
> >> + *	Pointer of the device structure.
> >> + *
> >> + * @return
> >> + *	0 on success.
> >> + *	!0 on error.
> >> + */
> >> +typedef int (*rte_bus_hotplug_handler_t)(struct rte_device *dev);
> > [...]
> >> @@ -211,6 +224,8 @@ struct rte_bus {
> >>   	rte_bus_parse_t parse;       /**< Parse a device name */
> >>   	struct rte_bus_conf conf;    /**< Bus configuration */
> >>   	rte_bus_get_iommu_class_t get_iommu_class; /**< Get iommu class */
> >> +	rte_bus_hotplug_handler_t hotplug_handler;
> >> +						/**< handle hot plug on bus */
> > The name is misleading.
> > It is to handle unplugging but is called "hotplug".
> 
> ok, so i prefer hotplug_failure_handler than hot_unplug_handler, since 
> it is more explicit for failure handle, and more clearly.
> 
> > In order to demonstrate how the handler is used, you should
> > introduce the code using this handler in the same patch.
> >
> 
> sorry, i check the history of rte_bus.h, and the way is introduce ops at 
> first, second implement in specific bus, then come across the usage.
> I think that way clear and make sense. what do you think?
> Anyway, i will check the commit log if is there any misleading.

I think it is better to call ops when they are introduced,
and implement the ops in second step.