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支持接口
在嵌入式智能家居设备应用比较多的操作系统还有亚马逊的freeRTOS, 是部分兼容posix()目前不到80%.从以下github仓库可以看具体兼容了哪些posix api:
Lab-Project-FreeRTOS-POSIX

车载系统中的应用

车载软件系统是一个很复杂的大规模嵌入式系统，一辆高度智能化的汽车可能会包含上千枚大大小小的芯片，因此必须要支持异构芯片。车载系统根据不同的功能可以分为多个不同的单元，或者叫做域。比如负责自动驾驶算法的AD自动驾驶域，控制车辆操控的控制域，进行图像识别的NN神经网络域，图像信号处理的ISP域，还有数字座舱域等。不同的域和单元根据功能需求和安全等级需求可能会跑不同的内核，常用的如Linux，safeRTOS,QNX等。除了这些通常还包括用作虚拟化管理的Hypervisor。如果你要设计一个车载中间件，而且这个中间件可能运行在上面提到的各种运行环境，各种内核里边，那么可移植性是必须要考虑的，这时就可能需要一个osal层来屏蔽不同的系统内核差异。

实际开发过程中，除了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。