OSAL操作系统抽象层

背景
我们知道操作系统可以简单的分为内核和上层应用。其中内核是用来管理计算机的各种硬件资源和软件资源，比如内存资源，cpu资源，网络资源，还有各种外设资源等等。而应用程序就是调用计算机的各种资源来完成特定的任务，比如需要申请内存来保存数据，需要申请网卡资源来发送数据等等。当然应用程序需要某个资源时需要向内核发出申请。而内核会向应用程序提供一些接口来申请资源，这些接口称之为系统调用。当然一般应用开发不会直接调用系统调用，因为使用不方便，一般调用的是各种标准库的接口，比如glibc.标准库对系统调用进行了封装管理，方便应用开发。比如应用程序申请动态内存可以使用malloc库函数申请资源，而在标准库内部的实现中，如果是在Linux内核中，是通过mmap或brk这两个系统调用来申请动态内存。

为什么需要操作系统抽象
一个简单的原因就是操作系统内核种类很多，而且很难统一。比较常见的内核比如Linux，Unix，Windows，在嵌入式领域还有其它很多的RTOS内核比如：UCOS,RreeRtos,RT-Thread,Liteos，AliOS等等。
由于不同操作系统的功能和系统调用接口往往不一样，目前也没有一个统一的标准，造成了嵌入式应用程序移植成本过高，另一方面程序员往往需要熟悉许多不同的开发环境，从而大大增加了嵌入式软件的开发成本。这使得能屏蔽下层不同操作系统，并提供统一调用接口的操作系统抽象层———OSAL 层（Operating System Abstraction Layer）成为必要.
这里以鸿蒙系统为例，作为一个面向iot的系统，它可能运行在不同的设备上面，可能是手机，可能是手表，可能是电视机，也有可能是电冰箱，等等。不同的设备拥有的能力和资源是不一样的，比如手机的cpu和内存是远远超过手表等小型嵌入式设备的。因此鸿蒙对操作系统进行了划分，分为标准系统和小系统，他们的内核可能不一样。手机等内存比较多的设备跑的是标准系统，系统内核是Linux内核。而手表跑的是小系统，内核是华为自研liteos.然后通过一个操作系统抽象层来对系统内核实现细节进行屏蔽，这样上层的应用开发就不用关注底下跑的是什么内核，这样即使以后把内核换成其它内核也不会影响到上层应用。
操作系统抽象层这个概念类似于鸿蒙的内核抽象层。
鸿蒙采用多内核（Linux内核或者LiteOS）设计，支持针对不同资源受限设备选用适合的OS内核。内核抽象层（KAL，Kernel Abstract Layer）通过屏蔽多内核差异，对上层提供基础的内核能力，包括进程/线程管理、内存管理、文件系统、网络管理和外设管理等。

POSIX标准
上文提到osal是为了屏蔽操作系统差异，但是如果所有的操作系统都遵循同一个标准呢？这就不得不提到POSIX标准。
POSIX的全称是可移植操作系统接口（Portable Operating System Interface of UNIX），是由IEEE 和ISO/IEC 开发的一簇标准。这个标准是基于现有的UNIX 实践和经验，定义了一些操作系统的调用服务接口，用于保证编制的应用程序可以在源代码一级上在多种操作系统上移植运行。
目前遵循posix标准的系统主要有Linux和Unix,国内一个比较著名的rtos RT-Thread也实现了大部分的posix接口,华为的小系统内核 LiteOS也提供了一套POSIX适配接口。他们的目的都是为了方便应用移植。
liteos具体适配了那些posix接口可以参考官网资料：POSIX支持接口

实际开发过程中，除了posix接口还会经常使用一些Linux，BSD,glic非标准的接口，或者其它标准的接口，比如ISO C99 C语言标准，C++标准。也就是仅仅兼容posix是远远不够的。
MUSL库
在鸿蒙系统中，是使用了一个开源库musl libc来做操作系统抽象。根据musl libc官方介绍，发行版系列涵盖了所有ISO C99和POSIX 2008 中定义的接口，以及一些Linux、BSD和Linux和glibc非标准化接口。
那为什么不用glibc呢？原因主要是glibc功能很全，函数很多，但是代码太多，编译出来的函数库的大小也很大，即资源占用也很多。而嵌入式系统中，也需要C语言写代码实现特定功能，也需要用到C语言函数库，但是由于嵌入式系统中，一般资源比较有限，所以不适合直接使用（太占用资源的）gLibc。

OSAL操作系统抽象层相关推荐

CC2540/CC2541/CC254x之OSAL操作系统抽象层
测试环境协议栈版本:BLE-CC254x-1.4.0 开发环境IAR版本:IAR 8.20 硬件设备:CC2540/CC2541开发板示例测试Demo工程:simpleBLEPeripheral工 ...
ZigBee学习之7——OSAL(操作系统抽象层)API解读
根据Z-Stack1.4.3-1.2.0中OSAL API_F8W-2003-0002_.pdf文档翻译. Z-Stack1.4.3及以后的版本中引入了一个OS的概念,把应用层和堆栈层进行了分离,但是 ...
OSAL（操作系统抽象层）
OSAL为Operating System Abstraction Layer,即操作系统抽象层,支持多任务运行,所有的应用程序(app)都在其上运行,它并不是一个传统意义上的操作系统,但是实现了部分 ...
WSF操作系统抽象层学习笔记 (五)---事件处理及运行方式
事件处理事件管理会创建一个OS的事件,用于进行WSF无运行需求时任务的阻塞. //事件管理结构 typedef struct {uint16_t param; //参数uint8_t event; ...
WSF操作系统抽象层学习笔记 (一) ---简介和内存管理
一.简介 WSF(wireless software foundation)是对操作系统的一个简单的封装,提供对操作系统的简单编程,提供简单的系统服务功能简介: 事件.消息传递和处理. 定时器功能. ...
WSF操作系统抽象层学习笔记（三）---消息列队
消息 WSF的消息服务用于传递消息到对应的事件处理句柄. 实现机制和使用方法基于内存管理,从内存中申请sizeof(wsfMsg_t) + 消息长度的内存.添加头部描述,返回给申请者除去头部的指针位 ...
WSF操作系统抽象层学习笔记（二）---列队（单向链表）
队列队列的管理使用单向链表结构.个人认为使用双向链表更易于维护. 注意: 每个以列队为基础管理的结构都必须将第一个元素设定为列队元件的指针. 进行列队操作时都需要关闭任务调度,防止多线程操作的信息同 ...
WSF操作系统抽象层学习笔记（四）---定时器
定时器定时器的实现方式: 使用OS自带的定时器模块,建立一个定时器,定时间隔为自定义TICKS,定时器的回调函数中设置定时器到时的事件. 定时器模块定义了一个定时器的链表,用于定时器的管理. 操作定 ...
zigbee之OSAL操作系统
概述 OSAL(Operating System AbstractionLayer),即操作系统抽象层. OSAL是一种基于事件驱动的轮询式操作系统,所提供的管理功能有: (1)任务登记.任务初始化. ...
OSAL操作系统实验学习笔记04
相信很多人接触了OSAL操作系统之后对它的任务资源分配机制还是很模糊,我细看了很多遍也还是略知一二,现在分享一篇我觉得写得特别好的文章. 深入浅出Z-Stack OSAL多任务资源分配机制一概述 ...

OSAL操作系统抽象层

OSAL操作系统抽象层相关推荐

最新文章

热门文章