[自制操作系统研究] 分享一下 HAL 硬件驱动系统的设计 (改:TypeAPI改为TypeDI)

MJK2012

我觉得是 XxTypeAPI 这个东西的命名太容易让人混淆了 .

API一般都是面向最终开发者的.  'A' 本来就是Application的意思.

看来, 有必要改名, 可以改成 XxTypeDI (Device Interface)

现在只是设计阶段. 以后可能会用不同的名字, 可以考虑 DPI (Device Programming Interface)

(已把楼顶的贴改为XxTypeDI)

linuxfellow

回复 11# MJK2012

从系统API -> XxTypeAPI 是如何实现的？  系统调用？
你把HAL放在 kernel，会不会让kernel太臃肿？
   

MJK2012

回复 12# linuxfellow

/// /// 从系统API -> XxTypeAPI 是如何实现的？  系统调用？

这里要分两种情况了. 内核与ring3进程.

在内核, 用系统API, 访问 XxTypeDI , 是直接的访问. 系统API能够直接取得 XxTypeDI  在内存的指针.

在ring3进程, 用系统API, 是先通过进程间通信模型, 发送二进制参数给内核, 内核检查二进制数据并且检查权限之后, 才去代理 XxTypeDI

可以这样看待, 虽然有一摸一样的 PlaySound 函数, 但是内核与ring3进程所加载的, 是完全不同的PlaySound代码.

API访问内核, 免除了中断或sysenter , 免除了权限检查, 能直接用指针, 性能将会远远超过ring3的模式.  

(同样 , 这也会超过Windows/Linux的ring3进程, 这就是为什么我第一帖分享操作系统目标的时候, 是以单内核进程作为它的常用方案了, 这种方案在嵌入式设备, 有较高的竞争力. )

/// /// 你把HAL放在 kernel，会不会让kernel太臃肿？

本来一开始设计的时候, 是打算一个驱动专用一个进程的. 这样可以随意地加载与卸载驱动.

后来我想了想, 很多时候我们还是要选一个平衡点, 用进程模式能带来更强大的功能, 但是也更加复杂了.

所以我最后决定先用内核的模式先 .


但是, 正如我之前描述的, 这个HAL是有很强的扩展能力的.

在以后的设计中, 完全可以实现单独进程的驱动. 理论上能谈得通. 楼顶列出的例子就有了类似的机制.




   

linuxfellow

回复 13# MJK2012
所以你用ipc模式来实现系统API到xXType DI;
所有的用户程序都直接ipc到内核去读取device driver.
有没有可能在用户空间做一个agent, 系统API发送device R/W请求到agent,由用户空间的agent通过系统调用去读取device driver; 这样很大一部分工作就能转移到用户空间。 这样会不会更好一些？


   

linuxfellow

回复 13# MJK2012
HAL是不能做在kernel里的。HAL的目的是为了增加application的可移植性。如果做在kernel里，kernel被换成其他操作系统，你的应用程序就不能运行了。HAL要被重写。


   

MJK2012

回复 14# linuxfellow


对. 可以的.  

这里关键就是权限的设计思路.

暂时我还没有设计到ring3进程的具体细节上, 连IPC都没设计.

我对ring3进程的概念就是, 先是0信任机制, ring3能访问的, 只是虚拟内存空间和被分到的可怜的CPU片段.


然后系统可以根据各种策略, 给ring3进程分配越来越多的资源.

这种模式, 很适合做受限的插件模型, 也很适合做类似手机APP之类的东西. 可以控制APP可以访问什么, 不可以访问什么.



但是HAL拥有很高的可扩展性, 它可以对请求进行各种形式的转发. 所以它可以转发到ring3进程上去.


谢谢你一下先, 我根据这个想法 , 写出了这个笔记 :




HAL OVER PROC

==== DEVICE OVER PROC

目的 :

让进程能编写驱动代码.

实现方式 :

系统向进程提供一些已存在的src-device-list.

进程通过这个src-device-list, 产生新的dst-device-list.


这个过程, 系统可以全程干预.

可以强制src-device,dst-device的规范.

进程无法访问到未授权的部分. 也不能模拟成未授权的设备类型.


产生的dst-device, 可以给哪些进程使用, 也是经过严格控制.


-----

同理, 可以实现

==== HOOK OVER DEVICE

原理大致相同. 细节以后再设计.

MJK2012

回复 15# linuxfellow

这个算是一个底层的HAL.

通过这个基本的HAL, 可以扩展出各种特殊的HAL .


Android就是类似这种模式.

由于Android是基于Linux, 所以Android必须开源, 连同内核的驱动也必须全部开源 .

这不是强迫硬件厂商把驱动的秘密公开了吗??

所以, google为了绕过这一点, 在Linux的HAL的基础上, 硬是搞了一个跨进程的外部HAL

这下好了, 硬件厂商的驱动, 不是Linux的一部分了, 而是一个插件 .

所以硬件厂商的驱动就绕过了Linux License的机制.


同样, 在这个OS里, 也可以做到这一点. 应用程序需要什么接口, 基于现在的HAL, 都能转换过来.

只不过就是, 他们访问的, 将会是不同的类型与函数了.

linuxfellow

回复 17# MJK2012
底层的HAL基本上是死路一条。相当于在内河HAL之间又没有必要的增加了一层。公司出于保密，规避公开代码，以及代码结构简洁的考虑都不会采用或实现公共的HAL. 不知有多少人愿意用linux HAL. 用了linux hal肯定还得在其上加一层； 因为linux hal未必是我的应用需要的。他也不可能完全满足我的要求。

   

MJK2012

回复 18# linuxfellow

只要底层的HAL有能扩展的能力, 就不用愁其他事了. 如何使用这个HAL, 如何把这个HAL转化为其他对象模型, 都没问题的.