HDF用户态和内核态之间是怎样调用的? 原创 精华

发布于 2022-2-17 21:11
浏览
1收藏

有兄弟在gitee的OpenHarmony/drivers_framework仓库提issue,见“HDF用户态和内核态之间是怎样调用的?

我看到了就做了简单回答如下,对鸿蒙驱动开发感兴趣或者有疑问的朋友,建议去gitee看原问答和其它相关issue的问答。

在标准系统中,HDF分用户态和内核态两部分,如何快速确定某个源文件是工作在用户态还是内核态?
可以搜索文件名,使用BUILD.gn构建成so的,是工作在用户态,使用Makefile构建的,是在内核态。

注意有部分文件是用户态和内核态共用的。

用户态驱动是以so库的形式存在吗?由哪个程序去负责加载这些so库,并将其注册到系统中?

drivers\adapter\uhdf2\host\src\driver_loader_full.c 的 HdfDriverLoaderGetDriverEntry()函数中,会通过两个strcat_s操作,拼接出用户态驱动so库的部署路径和库名,如:/system/lib/libsample_driver.z.so,通过realpath/dlopen/dlsym 来获取用户态驱动的入口 HdfDriverEntry,接下来就按流程执行其中的Bind/Init函数。

这个开发模型是否有详细的文档、框图等资料提供?

我已经完成了几乎整个HDF的详细分析,画出了详细的流程图和各模块之间的关系图,请关注即将出版的南向开发书籍《鸿蒙系统学习笔记》。

用户态驱动是如何注册到系统中的?

通过部署在用户态的hcs文件描述驱动配置信息,见//vendor/hisilicon/Hi3516DV300/hdf_config/uhdf/*.hcs
因为用户态驱动都是以动态库方式部署的,并且只对用户态提供服务,所以它的policy都是2,moduleName就是对应的动态库的全名。
编译和分析hcs/hcb文件,仍是hc-gen/hcs-parser。
解析hcb文件的过程和结果,见//drivers/adapter/uhdf2/manager/src/hdf_get_attribute.c内相关函数。

用户态驱动的so库如何告诉加载器自己是一个用户态驱动呢?

在//vendor/hisilicon/Hi3516DV300/hdf_config/uhdf/*.hcs里配置的驱动,都是用户态驱动,

一个用户态驱动是否能且仅能对外暴露一个driverDesc?

目前看起来是这样的,我有九成把握给肯定答案,但最好是官方确认一下。

用户态驱动的so库代码是运行在哪个进程上下文中?
所有用户态驱动的so库是运行在同一个进程上下文中吗?

hdf_devmgr进程是用户态设备驱动管理者进程,它不直接运行用户态驱动so库,它为每一个host fork一个子进程,每个子进程独立运行对应的host的so库,如sample_host进程运行libsample_driver.z.so

设备对象是由谁提供的?

每个设备驱动在执行自己的Bind/Init相关流程中,会生成DeviceServiceStub对象,里面会包含对应的HdfDeviceObject ,见HdfDriverLoaderLoadNode()内的操作。

调用逻辑大概如下。。。。但是这个逻辑是怎么开始的?后面又是如何通知到内核进行块设备注册的?

调用过程,有若干次hdf_devmgr进程和具体host进程之间的跨进程交互,你的逻辑还不完全准确。
我的书籍里给出了完整的交互过程和流程图,敬请关注。
用户态驱动不需要到内核进行注册,它对应用提供HDI接口,再通过系统调用进入内核态,使用内核态驱动提供的服务。

一个应用调用gralloc函数的流程。。。。。

display驱动模型我没有深入分析,但我深入分析了wlan驱动模型,相关流程估计可做参考,也请关注《鸿蒙系统学习笔记》这本书.

©著作权归作者所有,如需转载,请注明出处,否则将追究法律责任
7
收藏 1
回复
举报
回复
添加资源
添加资源将有机会获得更多曝光,你也可以直接关联已上传资源 去关联
    相关推荐