系统调用和库函数调用

liubingzhq

                （1）让我们忽略Linux对段式内存映射的支持。
在保护模式下，我们知道无论CPU运行于用户态还是核心态，CPU执行程序所访问的地址都是虚拟地址，MMU
必须通过读取控制寄存器CR3中的值作为当前页面目录的指针，进而根据分页内存映射机制（参看相关文档）将该虚拟地址转换为真正的物理地址才能让CPU真
正的访问到物理地址。
（2）对于32位的Linux，其每一个进程都有4G的寻址空间，但当一个进程访问其虚拟内存空间中的某个地址时又是怎样实现不与其它进程的虚拟空间混淆
的呢？每个进程都有其自身的页面目录PGD，Linux将该目录的指针存放在与进程对应的内存结构task_struct.(struct
mm_struct)mm->pgd中。每当一个进程被调度（schedule()）即将进入运行态时，Linux内核都要用该进程的PGD指针设
置CR3（switch_mm()）。
（3）当创建一个新的进程时，都要为新进程创建一个新的页面目录PGD，并从内核的页面目录swapper_pg_dir中复制内核区间页面目录项至新建进程页面目录PGD的相应位置，具体过程如下：
do_fork() --> copy_mm() --> mm_init() --> pgd_alloc() -->
set_pgd_fast() --> get_pgd_slow() --> memcpy(&PGD +
USER_PTRS_PER_PGD, swapper_pg_dir + USER_PTRS_PER_PGD, (PTRS_PER_PGD -
USER_PTRS_PER_PGD) * sizeof(pgd_t))
这样一来，每个进程的页面目录就分成了两部分，第一部分为“用户空间”，用来映射其整个进程空间（0x0000 0000－0xBFFF
FFFF）即3G字节的虚拟地址；第二部分为“系统空间”，用来映射（0xC000 0000－0xFFFF
FFFF）1G字节的虚拟地址。可以看出Linux系统中每个进程的页面目录的第二部分是相同的，所以从进程的角度来看，每个进程有4G字节的虚拟空间，
较低的3G字节是自己的用户空间，最高的1G字节则为与所有进程以及内核共享的系统空间。
（4）现在假设我们有如下一个情景：
在进程A中通过系统调用sethostname(const char *name,seze_t len)设置计算机在网络中的“主机名”.
在该情景中我们势必涉及到从用户空间向内核空间传递数据的问题，name是用户空间中的地址，它要通过系统调用设置到内核中的某个地址中。让我们看看这个
过程中的一些细节问题：系统调用的具体实现是将系统调用的参数依次存入寄存器ebx,ecx,edx,esi,edi（最多5个参数，该情景有两个
name和len），接着将系统调用号存入寄存器eax，然后通过中断指令“int
80”使进程A进入系统空间。由于进程的CPU运行级别小于等于为系统调用设置的陷阱门的准入级别3，所以可以畅通无阻的进入系统空间去执行为int
80设置的函数指针system_call()。由于system_call()属于内核空间，其运行级别DPL为0，CPU要将堆栈切换到内核堆栈，即
进程A的系统空间堆栈。我们知道内核为新建进程创建task_struct结构时，共分配了两个连续的页面，即8K的大小，并将底部约1k的大小用于
task_struct（如#define alloc_task_struct() ((struct task_struct *)
__get_free_pages(GFP_KERNEL,1))）,而其余部分内存用于系统空间的堆栈空间，即当从用户空间转入系统空间时，堆栈指针
esp变成了（alloc_task_struct()+8192），这也是为什么系统空间通常用宏定义current（参看其实现）获取当前进程的
task_struct地址的原因。每次在进程从用户空间进入系统空间之初，系统堆栈就已经被依次压入用户堆栈SS、用户堆栈指针ESP、EFLAGS、
用户空间CS、EIP，接着system_call()将eax压入，再接着调用SAVE_ALL依次压入ES、DS、EAX、EBP、EDI、ESI、
EDX、ECX、EBX，然后调用sys_call_table+4*%EAX，本情景为sys_sethostname()。
（5）在sys_sethostname()中，经过一些保护考虑后，调用copy_from_user(to,from,n），其中to指向内核空间
system_utsname.nodename，譬如0xE625A000，from指向用户空间譬如0x8010FE00。现在进程A进入了内核，在
系统空间中运行，MMU根据其PGD将虚拟地址完成到物理地址的映射，最终完成从用户空间到系统空间数据的复制。准备复制之前内核先要确定用户空间地址和
长度的合法性，至于从该用户空间地址开始的某个长度的整个区间是否已经映射并不去检查，如果区间内某个地址未映射或读写权限等问题出现时，则视为坏地址，
就产生一个页面异常，让页面异常服务程序处理。过程如
下：copy_from_user()->generic_copy_from_user()->access_ok()+__copy_user_zeroing().
（6）小结：
*进程寻址空间0~4G  
*进程在用户态只能访问0~3G，只有进入内核态才能访问3G~4G  
*进程通过系统调用进入内核态
*每个进程虚拟空间的3G~4G部分是相同的  
*进程从用户态进入内核态不会引起CR3的改变但会引起堆栈的改变
http://familyj.spaces.live.com/blog/cns!F3D148183B0189EE!566.entry
从程序完成的功能来看，函数库提供的函数通常是不需要操作系统的服务，函数是在用户空间内执行的，除非函数涉及到I/O操作等，一般是不会切到核心态的。系统调用是要求操作系统为用户提供进程，提供某种服务，通常是涉及系统的硬件资源和一些敏感的软件资源等。
函
数库的函数，尤其与输入输出相关的函数，大多必须通过Linux的系统调用来完成。因此我们可以将函数库的函数当成应用程序设计人员与系统调用程序之间的
一个中间层，通过这个中间层，我们可以用一致的接口来安全的调用系统调用。这样程序员可以只要写一次代码就能够在不同版本的linux系统间使用积压种具
体实现完全不同的系统调用。至于如何实现对不同的系统调用的兼容性问题，那是函数库开发者所关心的问题。
从程序执行效率来看，系统调用的
执行效率大多要比函数高，尤其是处理输入输出的函数。当处理的数据量比较小时，函数库的函数执行效率可能比较好，因为函数库的作法是将要处理的数据先存入
缓冲区内，等到缓冲区装满了，再将数据一次写入或者读出。这种方式处理小量数据时效率比较高，但是在进行系统调用时，因为用户进程从用户模式进入系统核心
模式，中间涉及了许多额外的任务的切换工作，这些操作称为上下文切换，此类的额外工作会影响系统的执行效率。但是当要处理的数据量比较大时，例如当输入输
出的数据量超过文件系统定义的尽寸时，利用系统调用可获得较高的效率。
从程序的可移植性的角度来看，相对于系统调用，C语言的标准备函数库（ANSI C） 具备较高的可移植性，在不同的系统环境下，只要做很少的修改，通常情况是不需要修改的。
[color="#1f497d"]Linux C中库函数和系统调用的区别
摘自：The Linux Kernel Module Programming Guide
库函数是高层的，完全运行在用户空间，
为程序员提供调用真正的在幕后完成实际事务的系统调用的更方便的接口。系统调用在内核态运行并且由内核自己提供。标准C库函数printf()可以被看做
是一个通用的输出语句，但它实际做的是将数据转化为符合格式的字符串并且调用系统调用 write()输出这些字符串。
是否想看一看printf()究竟使用了哪些系统调用? 这很容易，编译下面的代码。
＃include
int main(void)
{ printf("hello"); return 0; }   
使用命令gcc -Wall -o hello hello.c编译。用命令 strace hello
跟踪该可执行文件。是否很惊讶？ 每一行都和一个系统调用相对应。
strace是一个非常有用的程序，它可以告诉你程序使用了哪些系统调用和这些系统调用的参数，返回值。
这是一个极有价值的查看程序在干什么的工具。在输出的末尾，你应该看到这样类似的一行 write(1, "hello",
5hello)。这就是我们要找的。藏在面具printf() 的真实面目。既然绝大多数人使用库函数来对文件I/O进行操作(像 fopen,
fputs, fclose)。 你可以查看man说明的第二部分使用命令man 2 write
。man说明的第二部分专门介绍系统调用(像kill()和read())。
man说明的第三部分则专门介绍你可能更熟悉的库函数(像cosh()和random())。
你甚至可以编写代码去覆盖系统调用，正如我们不久要做的。骇客常这样做来为系统安装后门或木马。 但你可以用它来完成一些更有益的事，像让内核在每次某人删除文件时输出 “ Tee hee, that tickles!” 的信息。
http://familyj.spaces.live.com/blog/cns!F3D148183B0189EE!566.entry
整个系统调用的过程可以总结如下：

1． 执行用户程序(如:fork)

2． 根据glibc中的函数实现，取得系统调用号并执行int $0x80产生中断。

3． 进行地址空间的转换和堆栈的切换，执行SAVE_ALL。（进行内核模式）

4． 进行中断处理，根据系统调用表调用内核函数。

5． 执行内核函数。

6． 执行RESTORE_ALL并返回用户模式
               
               

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u2/67750/showart_2161893.html