HDF用户态和内核态之间是怎样调用的？

有兄弟在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驱动模型，相关流程估计可做参考，也请关注《鸿蒙系统学习笔记》这本书.

想了解更多关于鸿蒙的内容，请访问：

51CTO和华为官方合作共建的鸿蒙技术社区

https://ost.51cto.com/#bkwz