On 11/06/2019 06:56, Leon Romanovsky wrote:
On Tue, Jun 11, 2019 at 10:37:48AM +0800, wangxi wrote:
在 2019/6/10 21:27, Jason Gunthorpe 写道:
On Sat, Jun 08, 2019 at 10:24:15AM +0800, wangxi wrote:
Why is there an EXPROT_SYMBOL in a IB driver? I see many in
hns. Please send a patch to remove all of them and respin this.
There are 2 modules in our ib driver, one is hns_roce.ko, another
is hns_roce_hw_v2.ko. all extern symbols are named like hns_roce_xxx,
this function defined in hns_roce.ko, and invoked in
hns_roce_hw_v2.ko.
seems unnecessarily complicated
Jason
.
Hi,Jason,
The hns ib driver was originally designed for the hip06. When designing the
driver for the new hardware hip08, in order to maximize the reuse of the
existing hip06 code, the common part of the code is separated into the
hns_roce.ko, and the hardware difference code is defined into hns_roce_hw_v1.ko
for hip06 and hns_roce_hw_v2.ko for hip08.
The mtr code is designed as a public part in this patchset, so it is defined
in hns_roce.ko. It can be used for hi16xx series hardware with mixed mutihop
addressing feature. Currently, hip08 supports this feature, so it is be called
in hns_roce_hw_v2.ko.
Combine v1 and v2 into one driver (.ko) and change initialization to
call v1 or v2 accordingly. The rest is handled by ib_device_ops
structure.
Is there a rule which says that a driver cannot export symbols? Module
stacking is useful for more complex drivers, in that a hw-specific
implementation may plug into common driver. This helps code reuse.
In addition to this, v1 hw is a platform device driver and depends on
HNS, while v2 hw is for a PCI device and depends on PCI && HNS3.
Attempts to combine into a single ko would introduce messy dependencies
and ifdefs.
Thanks,
John
Thanks
Xi Wang
_______________________________________________
Linuxarm mailing list
Linuxarm@xxxxxxxxxx
http://hulk.huawei.com/mailman/listinfo/linuxarm
