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

瀚海书香

回复 1# MJK2012
多谢分享！

   

MJK2012

回复 2# 瀚海书香


不用谢. 不过我差点忘记在标题说明了. 这是我设计的OS的HAL哦. 不是Linux的架构.

linuxfellow

回复 1# MJK2012

从HAL到硬件 ，实现比较类似。
从程序到HAL，有没有什么讲究？
所有的用户都直接调用HAL API?

模式一：所有应用程序直接access IO
user1 程序--》HAL API-->driver
user2 程序--》HAL API-->driver
.....   
usern 程序--》HAL API-->driver

模式二：应用程序只能通过io manager access IO
user1 程序--》HAL_API-->io request --> IO manager-->driver
user2 程序--》HAL API-->io request --> IO manager-->driver
.....   
usern 程序--》HAL API-->io request --> IO manager-->driver

你采用模式一，所有应用程序直接access IO,这样数据流显得有点紊乱；模式二结构要清晰一些。  

MJK2012

回复 4# linuxfellow

用户程序, 有两种通道访问计算机硬件.

一, 调用 系统的API , 例如 PlaySound , 这种方式, 将会受到系统的配置影响. 例如系统会调节音量, 会禁止播放, 系统会根据用户选择一个合适的输出设备等等.

这是 : 程序 -> 系统API -> HAL API

二 , 调用 驱动的API , 这种方式更加像那些询问用户用哪个摄像头来做视频聊天的模式. 程序可以绕过系统API层, 直接访问HAL.
  (只允许内核进程这样搞, ring3进程必须通过系统不同级别的API, 或安装内核Module来代理)

这是 : 程序 -> HAL API


在我的设计里没有IO Manager这些东西的.

如果有的话, 也是在 系统API 那一层实现 IO Manager  , 那么方式就会成为

程序 -> 系统API -> IO Manager -> HAL API


如果你是说多任务对单个硬件进行访问的控制, 这个是在HAL内部实现 .

HAL的内部设计为 :

XxTypeAPI -> XxTypeImpl

其中 XxTypeAPI由系统定义也由系统实现 , XxTypeImpl由系统定义但是由驱动代码实现 .

那么上面的逻辑, 其实是这样 :

程序 -> 系统API -> XxTypeAPI -> XxTypeImpl

XxTypeAPI 内部要实现的内容, 应该就是指你说的 IO Manager

如果一个设备是XxTypeImpl 不允许同时访问的, 那么XxTypeAPI 会对请求进行排队.


这个是异步语言里非常容易实现的, 也是我后来决定要用异步语言来写HAL的原因.

linuxfellow

回复 5# MJK2012
我觉得应该是：
程序 -> 系统API -> HAL API-> IO Manager
   IO Manager 可能因为使用的os不同而不同，需要被HAL_API包裹。
还有你的系统API是什么？只能是application API, right?

MJK2012

回复 4# linuxfellow

再一次谢谢你的回复先.

这让我想起了系统API层的设计问题.

按我现在HAL的实现, 硬件的个数, 是不定量的.

一个系统里允许任何数量的键盘鼠标显示器.

我甚至打算让系统能用到一定的规则, 去把单个键盘鼠标显示器绑定在一起.

这样一个系统可以有多个桌面, 但和windows不同的是每个桌面都有它专用的键盘鼠标显示器.


而这些东西, 都是属于向应用程序分派相关硬件的逻辑.

在桌面1的界面, 就应该用到桌面1的键盘鼠标. 那么桌面1的代码在操作硬件的时候,

不是访问HAL去执行的, 而是访问系统API去做的. 系统API会根据程序的上下文, 自动找到合适的硬件.

这种关系是 :

程序 -> 系统API -> 找到合适的硬件设备 ->　HAL



一个程序, 是不应该知道那么多的. 系统应该为程序, 设计好一些基本的模型.

这个模型将把复杂的HAL的组合情况,  转化为简单的API

好像 PlaySound, 有声卡就播放就是. 程序也不想操心在那个硬件播放. 这是用户自己在ControlPanel里修改的选项.

程序也只需要用系统API去往一个Panel里画点东西就够了, 不管这个API最终会把东西画到显卡里还是送到一个预览窗口里去.


这些都是程序API的细节要思考的部分 , 也是应用程序开发人员最关心的部分了 .

而我的目标, 首先是去研究一下主流的可移植的库, 看看他们到底需要什么接口先.

等收集到足够的信息后, 才能去设计这一部分.









   

MJK2012

linuxfellow 发表于 2012-03-19 11:34
回复 5# MJK2012
我觉得应该是：
程序 -> 系统API -> HAL API-> IO Manager

我去查了一下 IO manager, 我找到了关于Windows IO Manager的描述 .

在Windows中, 它称硬件的依赖线路为 stacks , 而我则称它为 channel

例如 分区 -> 磁盘 -> USB -> PCI


对于Windows文章对IO Manager的描述 , 如果IO Manager是Windows的那种概念的话,

那么在我的设计中, IO Manager 是HAL的一部分 , 或者叫 Device Manager 更佳


它负责的是管理HAL的职能, 但是它不管系统的其他部分是如何使用这些HAL的 .

它算是负责建立一种'关系' , 它也可以取消这些'关系'

一旦关系存在着 , 我上面的哪些 程序->系统API->HAL->真的硬件 这个过程,  Manager 就不干预了.

linuxfellow

回复 5# MJK2012
再来讨论一下你的实现。

1。先统一一下概念： 系统API,应该是应用程序API.是应用程序要求的接口，而不是随操作系统，或硬件系统变化的系统API. 是不是这样？
2。 你的xxTpye API-->xxImpl API， 有几个instances在运行？ 在多地址空间的应用里，你是让每个地址空间都有自己的一个实例运行xxTpye API-->xxImpl API； 还是只有唯一的一个实例运行xxTpye API-->xxImpl API在某一个地址空间，而其他地址空间程序只能向该实例提要求，由该实例运行xxTpye API-->xxImpl API

   

MJK2012

回复 9# linuxfellow

 ////  //// 再来讨论一下你的实现。
////  //// 1。先统一一下概念： 系统API,应该是应用程序API.是应用程序要求的接口，而不是随操作系统，或硬件系统变化的系统API. 是不是这样？
////  //// 2。 你的xxTpye API-->xxImpl API， 有几个instances在运行？ 在多地址空间的应用里，你是让每个地址空间都有自己的一个实例运行xxTpye API-->xxImpl API； 还是只有唯一的一个实例运行xxTpye API-->xxImpl API在某一个地址空间，而其他地址空间程序只能向该实例提要求，由该实例运行xxTpye API-->xxImpl API
   
对, 我说的系统API, 或者程序API, 其实是指面向开发者的东西. 在这篇帖子里, 主要是指 PlaySound 这些玩意.

XxTypeAPI -> XxTypeImpl 这个是每个Device都会有的, 他们组成一对. 只不过API由系统实现, Impl由驱动代码实现.

有多少个Device, 就会有多少个这样的组合 . 例如如果有两个声卡, 那么就会有 双份的 SoundCardAPI -> SoundCardImpl

因为有多个 SoundCardAPI ,  系统在播放音乐的时候, 是需要一个选择声卡的过程. 这个过程由系统配置文件来实现不同的播放逻辑.

---

所有的这些HAL的东西都是在内核空间内, 而在ring3的进程空间里, 是不存在HAL的.

所以 无论有多个SoundCardAPI/SoundCardImpl , 他们都不会因为进程的增加而复制多份.

MJK2012

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

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

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

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

(已把楼顶的贴改为XxTypeDI)