[原创] Linux体系结构(四)： 内核空间和用户空间

前面几节主要对Linux的外在体系结构做了一些介绍，在这一节里，将分析一下Linux的内部结构，初略可以将这个内部体系划分为三层：Hardware => Kernel Space => User Space

1. 为什么要划分为内核空间和用户空间？
Linux Kernel是操作系统的核心，独立于普通的应用程序，可以访问受保护的内存空间，也有访问底层硬件设备的所有权限。

对于Kernel这么一个高安全级别的东西，显然是不容许其它的应用程序随便调用或访问的，所以需要对Kernel提供一定的保护机制，这个保护机制用来告诉那些应用程序，你只可以访问某些许可的资源，不许可的资源是拒绝被访问的，于是就把Kernel和上层的应用程序抽像的隔离开，分别称之为Kernel Space和User Space。

2. 用户空间的程序如何对内核空间进行访问？
上面说到用户态和内核态是两个隔离的空间，虽然从逻辑上被抽像的隔离，但无可避免的是,总是会有那么一些用户空间需要访问内核空间的资源，怎么办呢？

从上图结构中可以看出，Kernel Space层从下至上包括：

Arch：对应Kernel里arch目录，含有诸如x86, ia64, arm, s390等体系结构的支持；

Device Driver：对应Kernel里drivers目录，含有block, char, net, usb等不同硬件驱动的支持；

在Arch和Driver之上，是对内存，进程，文件系统，网络协议栈等的支持；

 

最上一层是System Call Interface，系统调用接口，正如其名，这层就是用户空间与内核空间的桥梁，用户空间的应用程序通过System Call这个统一入口来访问系统中的硬件资源，通过此接口，所有的资源访问都是在内核的控制下执行，以免导致对用户程序对系统资源的越权访问，从而保障了系统的安全和稳定。

 

3. glibc库的作用

在用户空间一层，可以看到有glibc库的存在，这里之所以把它单独列出来强调，是因为一般用户空间的程序不会直接调用内核的System Call去访问系统资源，而是由glibc这样的库间接去调用System Call,换言之，glibc对Kernel的System Call做了一层封装。

 

4. Kernel的C库与glibc的C库

之前强调过，Kernel是相对独立的存在，不依赖于任何用户空间的程序或库，而大家都知道Kernel除了少量的汇编代码，大多数都是由C语言编写，glibc库属于用户空间，没有glibc库的支持，Kernel又是如何去处理C语言相关的代码呢？

 

在Kernel的目录结构中，有lib这么一个目录，此目录里含有kernel自己的C库，比如字符串处理相关函数封装在string.c文件中，比如排序相关的代码封闭在sort.c文件中，调用的时候使用：

#include <linux/string.h> #include <linux/sort.h>

 

而对于用空间glibc库的调用则是：

#include <string.h> #include <memcopy.h>