uadk: adjust internal file include relationships #529
Conversation
Liulongfang
requested review from
hzhuang1,
gaozhangfei,
haofang111 and
youngersh
|
There is uadk_file_relationship.svg, is that required? |
This svg diagram is added to save the current file relationship diagram so that users can understand its structure. |
it will be destined to be outdated since it is too concrete. |
If it is possible to generate this relationship diagram through a command, that is fine. What is this command? |
|
I don't know, how do you get this pic? |
|
Anyway, it's only my opinion no need to maintain this relationship pic, it is up to you. |
This pic is drawn by myself, not generated by command |
My opinion is to keep it, after all, it is still beneficial for UADK users to understand UADK's software framework. |
In the current UADK software framework, because each module owner processes the code separately when editing the code, the header file inclusion processing during editing is not perfect, and there are repeatedly included header files, which need to be deleted. Signed-off-by: liulongfang <liulongfang@huawei.com>
Adjust the header file inclusion logic to ensure that the data structures used internally are not exposed to the outside world. Also, remove unused header file wd_common.h Signed-off-by: liulongfang <liulongfang@huawei.com>
Clarify the file relationship diagram of UADK, follow-up UADK framework evolution, continue to ensure that the logic of the basic file inclusion relationship is reasonable. Signed-off-by: Longfang Liu <liulongfang@huawei.com>
|
/lgtm |
|
Ack |
The file inclusion relationship in the current uadk is confusing, and there are multiple repeated inclusions, which leads to confusion in the internal inclusion relationship.
On the adjusted UADK, I divide UADK users into two categories: business users and developer users.
Business users only need to pay attention to how to use UADK to perform data acceleration services.
Developer users only need to focus on adapting their devices to the UADK framework.
According to the different demands of these two types of users on UADK, the external interface is divided into two different headers. In this way, business users only need to obtain the required interface through “wd.h“ to fully realize their own acceleration business, and do not need to pay attention to how the device they use is driven. Developer users only need to use ”wd_util.h“ to obtain the interface required to adapt a device driver to uadk, without paying attention to how their own devices are used by users.
In this way, both types of users only need to learn and understand the interfaces in their respective header files to complete their demands.
PR reviewed before: #527
This PR rebased on: #520