[dpdk-dev] [PATCH V4 1/9] bus: introduce hotplug failure handler

[Guo, Jia]

On 7/4/2018 3:55 PM, Thomas Monjalon wrote:
> 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.
>

Hi, Thomas

sorry but i want to detail the relationship of the ops and api as bellow 
to try if we can get the better sequence.

Patch num:

1: introduce ops hotplug_failure_handler

2: implement ops hotplug_failure_handler

3:introduce ops sigbus_handler.

4:implement ops sigbus_handler

5: introduce helper rte_bus_sigbus_handler to call the ops sigbus_handler

6: introduce the mechanism to call helper rte_bus_sigbus_handler and 
call hotplug_failure_handler.

If per you said , could I modify the sequence like 6->5->3->4->1->2? I 
don't think it will make sense, and might be more confused.

And I think should be better that introduce each ops just say item, then 
when introduce the caller patch, the functional is ready to use by the 
patch.


if i did not got your point and you have other better sequence about 
that please explicit to let me know. Thanks.