nginx-1.0.4源码分析—内存池结构ngx_pool_t及内存管理

nginx-1.0.4源码分析—内存池结构ngx_pool_t及内存管理
nginx-1.0.4源码分析—内存池结构ngx_pool_t及内存管理

Content

0. 序

1. 内存池结构

1.1 ngx_pool_t结构

1.2 其他相关结构

1.3 ngx_pool_t的逻辑结构

2. 内存池操作

2.1 创建内存池

2.2 销毁内存池

2.3 重置内存池

2.4 分配内存

2.4.1 ngx_palloc()函数分析

2.4.2 ngx_palloc_block()函数分析2.5 释放内存

2.6 注册cleanup

2.7 内存池的物理结构

3. 一个例子

3.1 代码

3.2 如何编译

3.3 运行结果

4. 小结

5. 致谢

0. 序

nginx对内存的管理由其自己实现的内存池结构ngx_pool_t来完成,本文重点叙述nginx的内存管理。

nginx内存管理相关文件:

(1) ./src/os/unix/ngx_alloc.h/.c

?内存相关的操作,封装了最基本的内存分配函数

?如free/malloc/memalign/posix_memalign,分别被封装为ngx_free,

ngx_alloc/ngx_calloc, ngx_memalign

?ngx_alloc:封装malloc分配内存

?ngx_calloc:封装malloc分配内存,并初始化空间内容为0

?ngx_memalign:返回基于一个指定alignment的大小为size的内存空间,且其地址为alignment的整数倍,alignment为2的幂。

(2) ./src/core/ngx_palloc.h/.c

?封装创建/销毁内存池,从内存池分配空间等函数

.表示nginx-1.0.4代码目录,本文为/usr/src/nginx-1.0.4。

1. 内存池结构

nginx对内存的管理均统一完成,例如,在特定的生命周期统一建立内存池(如main函数系统启动初期即分配1024B大小的内存池),需要内存时统一分配内存池中的内存,在适当的时候释放内存池的内存(如关闭http链接时调用ngx_destroy_pool进行销毁)。

因此,开发者只需在需要内存时进行申请即可,不用过多考虑内存的释放等问题,大大提高了开发的效率。先看一下内存池结构。

1.1 ngx_pool_t结构

此处统一一下概念,内存池的数据块:即分配内存在这些数据块中进行,一个内存池可以有多一个内存池数据块。nginx的内存池结构如下。

00048: typedef struct {

00049: u_char *last; //当前内存池分配到此处,即下一次分配从此处开始

00050: u_char *end; //内存池结束位置

00051: ngx_pool_t *next; //内存池里面有很多块内存,这些内存块就是通过该指针连成链表的

00052: ngx_uint_t failed; //内存池分配失败次数

00053: } ngx_pool_data_t; //内存池的数据块位置信息

00054:

00055:

00056: struct ngx_pool_s{ //内存池头部结构

00057: ngx_pool_data_t d; //内存池的数据块

00058: size_t max; //内存池数据块的最大值

00059: ngx_pool_t *current; //指向当前内存池

00060: ngx_chain_t *chain; //该指针挂接一个ngx_chain_t结构

00061: ngx_pool_large_t *large; //大块内存链表,即分配空间超过max的内存00062: ngx_pool_cleanup_t *cleanup; //释放内存池的callback

00063: ngx_log_t *log; //日志信息

00064: };

其中,sizeof(ngx_pool_data_t)=16B,sizeof(ngx_pool_t)=40B。

nginx将几乎所有的结构体放在ngx_core.h文件中重新进行了申明,如下。typedef struct ngx_module_s ngx_module_t;

typedef struct ngx_conf_s ngx_conf_t;

typedef struct ngx_cycle_s ngx_cycle_t;

typedef struct ngx_pool_s ngx_pool_t;

typedef struct ngx_chain_s ngx_chain_t;

typedef struct ngx_log_s ngx_log_t;

typedef struct ngx_array_s ngx_array_t;

typedef struct ngx_open_file_s ngx_open_file_t;

typedef struct ngx_command_s ngx_command_t;

typedef struct ngx_file_s ngx_file_t;

typedef struct ngx_event_s ngx_event_t;

typedef struct ngx_event_aio_s ngx_event_aio_t;

typedef struct ngx_connection_s ngx_connection_t;

1.2 其他相关结构

其他与内存池相干的数据结构,如清除资源的cleanup链表,分配的大块内存链表等,如下。

00015: /*

00016: * NGX_MAX_ALLOC_FROM_POOL should be (ngx_pagesize - 1), i.e. 4095 on

x86.

00017: * On Windows NT it decreases a number of locked pages in a kernel.

00018: */

00019: #define NGX_MAX_ALLOC_FROM_POOL (ngx_pagesize - 1) //在x86体系结构下,该值一般为4096B,即4K

00020:

00021: #define NGX_DEFAULT_POOL_SIZE (16* 1024)

00022:

00023: #define NGX_POOL_ALIGNMENT 16

00024: #define NGX_MIN_POOL_SIZE \

00025: ngx_align((sizeof(ngx_pool_t) + 2 * sizeof(ngx_pool_large_t)), \

00026: NGX_POOL_ALIGNMENT)

00027:

00028:

00029: typedef void (*ngx_pool_cleanup_pt)(void *data); //cleanup的callback类型00030:

00031: typedef struct ngx_pool_cleanup_s ngx_pool_cleanup_t;

00032:

00033: struct ngx_pool_cleanup_s{

00034: ngx_pool_cleanup_pt handler;

00035: void *data; //指向要清除的数据

00036: ngx_pool_cleanup_t *next; //下一个cleanup callback

00037: };

00038:

00039:

00040: typedef struct ngx_pool_large_s ngx_pool_large_t;

00041:

00042: struct ngx_pool_large_s{

00043: ngx_pool_large_t *next; //指向下一块大块内存

00044: void *alloc; //指向分配的大块内存

00045: };

...

...

00067: typedef struct {

00068: ngx_fd_t fd;

00069: u_char *name;

00070: ngx_log_t *log;

00071: } ngx_pool_cleanup_file_t;

00072:

(gdb) p getpagesize()

$18 = 4096

全局变量ngx_pagesize的初始化是在如下函数中完成的。./src/os/unix/ngx_posix_init.c ngx_int_t

ngx_os_init(ngx_log_t *log)

{

ngx_uint_t n;

#if (NGX_HAVE_OS_SPECIFIC_INIT)

if (ngx_os_specific_init(log) != NGX_OK) {

return NGX_ERROR;

}

#endif

ngx_init_setproctitle(log);

/** 该函数为glibc的库函数,由系统调用实现,返回内核中的PAGE_SIZE,该值依赖体系结构*/

ngx_pagesize = getpagesize();

ngx_cacheline_size = NGX_CPU_CACHE_LINE;

...

}

这些数据结构之间的关系,请参考后面的图。

1.3 ngx_pool_t的逻辑结构

这些数据结构逻辑结构图如下。注:本文采用UML的方式画出该图。

2. 内存池操作

2.1 创建内存池

创建内存池有ngx_create_pool()函数完成,代码如下。

00015: ngx_pool_t *

00016: ngx_create_pool(size_t size, ngx_log_t *log)

00017: {

00018: ngx_pool_t *p;

00019:

00020: p = ngx_memalign(NGX_POOL_ALIGNMENT, size, log);

00021: if (p == NULL) {

00022: return NULL;

00023: }

00024:

00025: p->https://www.360docs.net/doc/a19778083.html,st = (u_char *) p + sizeof(ngx_pool_t); //last指向ngx_pool_t结构体之后数据取起始位置

00026: p->d.end = (u_char *) p + size; //end指向分配的整个size大小的内存的末尾

00027: p->d.next = NULL;

00028: p->d.failed = 0;

00029:

00030: size = size - sizeof(ngx_pool_t);

00031: p->max = (size < NGX_MAX_ALLOC_FROM_POOL) ? size :

NGX_MAX_ALLOC_FROM_POOL; //最大不超过4095B

00032:

00033: p->current = p;

00034: p->chain = NULL;

00035: p->large = NULL;

00036: p->cleanup = NULL;

00037: p->log = log;

00038:

00039: return p;

00040: }

例如,调用ngx_create_pool(1024, 0x80d1c4c)后,创建的内存池物理结构如下图。

2.2 销毁内存池

销毁内存池由如下函数完成。

void ngx_destroy_pool(ngx_pool_t *pool)

该函数将遍历内存池链表,所有释放内存,如果注册了clenup(也是一个链表结构),亦将遍历该cleanup链表结构依次调用clenup的handler清理。同时,还将遍历large链表,释放大块内存。

2.3 重置内存池

重置内存池由下面的函数完成。

void ngx_reset_pool(ngx_pool_t *pool);

该函数将释放所有large内存,并且将d->last指针重新指向ngx_pool_t结构之后数据区的开始位置,同刚创建后的位置相同。

2.4 分配内存

内存分配的函数如下。

void *ngx_palloc(ngx_pool_t *pool, size_t size);

void *ngx_pnalloc(ngx_pool_t *pool, size_t size);

void *ngx_pcalloc(ngx_pool_t *pool, size_t size);

void *ngx_pmemalign(ngx_pool_t *pool, size_t size, size_t alignment);

返回值为分配的内存起始地址。选择其中的两个函数进行分析,其他的也很好理解,省略。

2.4.1 ngx_palloc()函数分析

ngx_palloc()代码如下,分析请参考笔者所加的注释。

00115: void *

00116: ngx_palloc(ngx_pool_t *pool, size_t size)

00117: {

00118: u_char *m;

00119: ngx_pool_t *p;

00120:

00121: if (size <= pool->max) {//判断待分配内存与max值

00122:

00123: p = pool->current; //小于max值,则从current节点开始遍历pool链表00124:

00125: do {

00126: m = ngx_align_ptr(p->https://www.360docs.net/doc/a19778083.html,st, NGX_ALIGNMENT);

00127:

00128: if ((size_t) (p->d.end - m) >= size) {

00129: p->https://www.360docs.net/doc/a19778083.html,st = m + size; //在该节点指向的内存块中分配size大小的内存

00130:

00131: return m;

00132: }

00133:

00134: p = p->d.next;

00135:

00136: } while (p);

00137:

00138: return ngx_palloc_block(pool, size); //链表里没有能分配size大小内存的节点,则生成一个新的节点并在其中分配内存

00139: }

00140:

00141: return ngx_palloc_large(pool, size); //大于max值,则在large链表里分配内存

00142: }

例如,在2.1节中创建的内存池中分配200B的内存,调用ngx_palloc(pool, 200)后,该内存池物理结构如下图。

2.4.2 ngx_palloc_block()函数分析

ngx_palloc_block函数代码如下,分析请参考笔者所加的注释。00175: static void *

00176: ngx_palloc_block(ngx_pool_t *pool, size_t size) 00177: {

00178: u_char *m;

00179: size_t psize;

00180: ngx_pool_t *p, *new, *current;

00181:

00182: psize = (size_t) (pool->d.end - (u_char *) pool); //计算pool的大小

00183:

00184: m = ngx_memalign(NGX_POOL_ALIGNMENT, psize, pool->log);//分配一块与pool大小相同的内存

00185: if (m == NULL) {

00186: return NULL;

00187: }

00188:

00189: new = (ngx_pool_t *) m;

00190:

00191: new->d.end = m + psize; //设置end指针

00192: new->d.next = NULL;

00193: new->d.failed = 0;

00194:

00195: m += sizeof(ngx_pool_data_t); //让m指向该块内存ngx_pool_data_t结构体之后数据区起始位置

00196: m = ngx_align_ptr(m, NGX_ALIGNMENT); //按4字节对齐

00197: new->https://www.360docs.net/doc/a19778083.html,st = m + size; //在数据区分配size大小的内存并设置last指针

00198:

00199: current = pool->current;

00200:

00201: for (p = current; p->d.next; p = p->d.next) {

00202: if (p->d.failed++ > 4) { //failed的值只在此处被修改

00203: current = p->d.next; //失败4次以上移动current指针

00204: }

00205: }

00206:

00207: p->d.next = new; //将这次分配的内存块new加入该内存池

00208:

00209: pool->current = current ? current : new;

00210:

00211: return m;

00212: }

注意:该函数分配一块内存后,last指针指向的是ngx_pool_data_t结构体(大小16B)之后数据区的起始位置。而创建内存池时时,last指针指向的是ngx_pool_t结构体(大小40B)之后数据区的起始位置。

结合2.7节的内存池的物理结构,更容易理解。

2.5 释放内存

请参考如下函数,不再赘述。

ngx_int_t ngx_pfree(ngx_pool_t *pool, void *p)

需要注意的是该函数只释放large链表中注册的内存,普通内存在ngx_destroy_pool中统一释放。

2.6 注册cleanup

请参考如下函数,该函数实现也很简单,此处不再赘述。

ngx_pool_cleanup_t *ngx_pool_cleanup_add(ngx_pool_t *p, size_t size)

2.7 内存池的物理结构

针对本文第3节的例子,画出的内存池的物理结构如下图。

从该图也能看出2.4节的结论,即内存池第一块内存前40字节为ngx_pool_t结构,后续加入的内存块前16个字节为ngx_pool_data_t结构,这两个结构之后便是真正可以分配内存区域。

因此,本文Reference中的内存分配相关中的图是有一点点小问题的,并不是每一个节点的前面都是ngx_pool_t结构。

3. 一个例子

理解并掌握开源软件的最好方式莫过于自己写一些测试代码,或者改写软件本身,并进行调试来进一步理解开源软件的原理和设计方法。本节给出一个创建内存池并从中分配内存的简单例子。

3.1 代码

ngx_pool_t_test.c

3.2 如何编译

这个问题是编写测试代码或者改写软件本身最迫切需要解决的问题,否则,编写的代码无从编译或运行,那也无从进行调试并理解软件了。

如何对自己编写的测试代码进行编译,可参考Linux平台代码覆盖率测试-编译过程自动化及对链接的解释、Linux平台如何编译使用Google test写的单元测试?。我们要做的是学习这种编译工程的方法,针对该例子,笔者编写的makefile文件如下。——这便是本节的主要目的。

CXX = gcc

CXXFLAGS += -g -Wall -Wextra

NGX_ROOT = /usr/src/nginx-1.0.4

TARGETS = ngx_pool_t_test

TARGETS_C_FILE = $(TARGETS).c

CLEANUP = rm -f $(TARGETS) *.o

all: $(TARGETS)

clean:

$(CLEANUP)

CORE_INCS = -I. \

-I$(NGX_ROOT)/src/core \

-I$(NGX_ROOT)/src/event \

-I$(NGX_ROOT)/src/event/modules \

-I$(NGX_ROOT)/src/os/unix \

-I$(NGX_ROOT)/objs \

NGX_PALLOC = $(NGX_ROOT)/objs/src/core/ngx_palloc.o NGX_STRING = $(NGX_ROOT)/objs/src/core/ngx_string.o NGX_ALLOC = $(NGX_ROOT)/objs/src/os/unix/ngx_alloc.o

Android Hotfix 新方案——Amigo 源码解读

Android Hotfix 新方案——Amigo 源码解读 首先我们先来看看如何使用这个库。 用法 在project 的build.gradle中 dependencies { classpath 'me.ele:amigo:0.0.3' } 在module 的build.gradle中 apply plugin: 'me.ele.amigo' 就这样轻松的集成了Amigo。 生效补丁包 补丁包生效有两种方式可以选择: ? 稍后生效补丁包 ? 如果不想立即生效而是用户第二次打开App 时才打入补丁包,则可以将新的Apk 放到/data/data/{your pkg}/files/amigo/demo.apk,第二次打开时就会自动生效。可以通过这个方法 ? File hotfixApk = Amigo.getHotfixApk(context); ?

获取到新的Apk。 同时,你也可以使用Amigo 提供的工具类将你的补丁包拷贝到指定的目录当中。 ? FileUtils.copyFile(yourApkFile, amigoApkFile); ? ? 立即生效补丁包 ? 如果想要补丁包立即生效,调用以下两个方法之一,App 会立即重启, 并且打入补丁包。 ? Amigo.work(context); ? Amigo.work(context, apkFile); ? 删除补丁包 如果需要删除掉已经下好的补丁包,可以通过这个方法 Amigo.clear(context); 提示:如果apk 发生了变化,Amigo 会自动清除之前的apk。 自定义界面 在热修复的过程中会有一些耗时的操作,这些操作会在一个新的进程中的Activity 中执行,所以你可以通过以下方式来自定义这个Activity。

内存管理模型的设计与实现

操作系统课程实验报告 学生姓名:尹朋 班学号:111131 指导教师:袁国斌 中国地质大学信息工程学院 2015年1月4日

实习题目:内存管理模型的设计与实现 【需求规格说明】 对内存的可变分区申请采用链表法管理进行模拟实现。要求: 1.对于给定的一个存储空间自己设计数据结构进行管理,可以使用单个链 表,也可以使用多个链表,自己负责存储空间的所有管理组织,要求采用分页方式(指定单元大小为页,如4K,2K,进程申请以页为单位)来组织基本内容; 2.当进程对内存进行空间申请操作时,模型采用一定的策略(如:首先利用 可用的内存进行分配,如果空间不够时,进行内存紧缩或其他方案进行处理)对进程给予指定的内存分配; 3.从系统开始启动到多个进程参与申请和运行时,进程最少要有3个以上, 每个执行申请的时候都要能够对系统当前的内存情况进行查看的接口; 4.对内存的申请进行内存分配,对使用过的空间进行回收,对给定的某种页 面调度进行合理的页面分配。 5.利用不同的颜色代表不同的进程对内存的占用情况,动态更新这些信息。 【算法设计】 (1)设计思想: 通过建立一个链表,来描述已分配和空闲的内存分区。对于每一个分区,它可能存放了某个进程,也可能是两个进程间的空闲区。链表中的每一个结点,分别描述了一个内存分区,包括它的起始地址、长度、指向下一个结点的指针以及分区的当前状态。 在基于链表的存储管理中,当一个新的进程到来时,需要为它分配内存空间,即为它寻找某个空闲分区,该分区的大小必须大于或等于进程的大小. 最先匹配法:假设新进程的大小为M,那么从链表的首节点开始,将每一个空闲节点的大小与M相比较,直到找到合适的节点.这种算法查找的节点很少,因而速度很快. 最佳匹配算法:搜索整个链表,将能够装得下该进程的最小空闲区分配出去. 最坏匹配法:在每次分配的时候,总是将最大的那个空闲区切去一部分,分配给请求者.它的依据是当一个很大的空闲区被切割成一部分后,可能仍然是一个比较大的空闲区,从而避免了空闲区越分越小的问题. (2)设计表示: 分区结点设计: template class ChainNode { friend Chain; public:

Nginx源代码解析

Nginx源代码解析 1.Nginx代码的目录和结构 nginx的源码目录结构层次明确,从自动编译脚本到各级的源码,层次都很清晰,是一个大型服务端软件构建的一个范例。以下是源码目录结构说明: ├─auto 自动编译安装相关目录 │├─cc 针对各种编译器进行相应的编译配置目录,包括Gcc、Ccc等 │├─lib 程序依赖的各种库,包括md5,openssl,pcre等 │├─os 针对不同操作系统所做的编译配置目录 │└─types ├─conf 相关配置文件等目录,包括nginx的配置文件、fcgi相关的配置等 ├─contrib ├─html index.html └─src 源码目录 ├─core 核心源码目录,包括定义常用数据结构、体系结构实现等 ├─event 封装的事件系统源码目录 ├─http http服务器实现目录 ├─mail 邮件代码服务器实现目录 ├─misc 该目录当前版本只包含google perftools包 └─os nginx对各操作系统下的函数进行封装以及实现核心调用的目录。2.基本数据结构 2.1.简单的数据类型 在core/ngx_config.h 目录里面定义了基本的数据类型的映射,大部分都映射到c语言自身的数据类型。 typedef intptr_t ngx_int_t; typedef uintptr_t ngx_uint_t; typedef intptr_t ngx_flag_t; 其中ngx_int_t,nginx_flag_t,都映射为intptr_t;ngx_uint_t映射为uintptr_t。 这两个类型在/usr/include/stdint.h的定义为: /* Types for `void *' pointers. */ #if __WORDSIZE == 64 # ifndef __intptr_t_defined

Android源码下载方法详解

Android: Android源码下载方法详解 分类:Android平台 安卓源码下载地址:https://www.360docs.net/doc/a19778083.html,/source/downloading.html 相信很多下载过内核的人都对这个很熟悉 git clone git://https://www.360docs.net/doc/a19778083.html,/kernel/common.git kernel 但是这是在以前,现在如果这么执行的话,会显示如下内容 Initialized empty Git repository in /home/star/working/kernel/.git/ https://www.360docs.net/doc/a19778083.html,[0: 149.20.4.77]: errno=Connection refused fatal: unable to connect a socket (Connection refused) 通过浏览器输入https://www.360docs.net/doc/a19778083.html,/,发现该网站已经被重定向为 https://www.360docs.net/doc/a19778083.html,/source/downloading.html 可以在该页面的最后发现内核的下载方法。 下面我们介绍一下Android源码下载的步骤。 工作环境: 操作系统:Ubuntu 10.04 或Ubuntu10.10 git程序:1.7.0.4 或1.7.1 转载请注明出处:https://www.360docs.net/doc/a19778083.html,/pku_android 方法一: 1.1 初始化安装环境 参考网页https://www.360docs.net/doc/a19778083.html,/source/initializing.html 主要要做的就是安装jdk和安装一些软件包 $ sudo apt-get install git-core gnupg flex bison gperf build-essential \ zip curl zlib1g-dev libc6-dev libncurses5-dev x11proto-core-dev \ libx11-dev libreadline6-dev libgl1-mesa-dev tofrodos python-markdown \ libxml2-utils 如果已经安装了,就不许要这步了 1.2 无论下载内核和源码,都需要进行如下操作 参考网页https://www.360docs.net/doc/a19778083.html,/source/downloading.html $ mkdir ~/bin $ PATH=~/bin:$PATH $ curl https://https://www.360docs.net/doc/a19778083.html,/dl/googlesource/git-repo/repo > ~/bin/repo 如果出现: repo init error: could not verify the tag 'v1.12.7',

基于可重定位分区分配算法的内存管理的设计与实现

组号成绩 计算机操作系统 课程设计报告 题目基于可重定位分区分配算法的内存管理的设计与实现 专业:计算机科学与技术 班级: 学号+: 指导教师: 2016年12月23 日

一.设计目的 掌握内存的连续分配方式的各种分配算法 二.设计内容 基于可重定位分区分配算法的内存管理的设计与实现。本系统模拟操作系统内存分配算法的实现,实现可重定位分区分配算法,采用PCB定义结构体来表示一个进程,定义了进程的名称和大小,进程内存起始地址和进程状态。内存分区表采用空闲分区表的形式来模拟实现。要求定义与算法相关的数据结构,如PCB、空闲分区;在使用可重定位分区分配算法时必须实现紧凑。 三.设计原理 可重定位分区分配算法与动态分区分配算法基本上相同,差别仅在于:在这种分配算法中,增加了紧凑功能。通常,该算法不能找到一个足够大的空闲分区以满足用户需求时,如果所有的小的空闲分区的容量总和大于用户的要求,这是便须对内存进行“紧凑”,将经过“紧凑”后所得到的大空闲分区分配给用户。如果所有的小空闲分区的容量总和仍小于用户的要求,则返回分配失败信息 四.详细设计及编码 1.模块分析 (1)分配模块 这里采用首次适应(FF)算法。设用户请求的分区大小为u.size,内存中空闲分区大小为m.size,规定的不再切割的剩余空间大小为size。空闲分区按地址递增的顺序排列;在分配内存时,从空闲分区表第一个表目开始顺序查找,如果m.size≥u.size且m.size-u.size≤size,说明多余部分太小,不再分割,将整个分区分配给请求者;如果m.size≥u.size且 m.size-u.size>size,就从该空闲分区中按请求的大小划分出一块内存空间分配给用户,剩余的部分仍留在空闲分区表中;如果m.size

nginx源码分析

nginx源码分析 nginx源码分析(1)- 缘起 nginx是一个开源的高性能web服务器系统,事件驱动的请求处理方式和极其苛刻的资源使用方式,使得nginx成为名副其实的高性能服务器。 nginx的源码质量也相当高,作者“家酿”了许多代码,自造了不少轮子,诸如内存池、缓冲区、字符串、链表、红黑树等经典数据结构,事件驱动模型,http解析,各种子处理模块,甚至是自动编译脚本都是作者根据自己的理解写出来的,也正因为这样,才使得nginx比其他的web服务器更加高效。 nginx 的代码相当精巧和紧凑,虽然全部代码仅有10万行,但功能毫不逊色于几十万行的apache。不过各个部分之间耦合的比较厉害,很难把其中某个部分的实现拆出来使用。对于这样一个中大型的复杂系统源码进行分析,是有一定的难度的,刚开始也很难找到下手的入口,所以做这样的事情就必须首先明确目标和计划。 最初决定做这件事情是为了给自己一些挑战,让生活更有意思。但看了几天之后,觉得这件事情不该这么简单看待,这里面有太多吸引人的东西了,值得有计划的系统学习和分析。首先这个系统中几乎涵盖了实现高性能服务器的各种必杀技,epoll、kqueue、master-workers、pool、 buffer……,也涵盖了很多web服务开发方面的技术,ssi、ssl、proxy、gzip、regex、load balancing、reconfiguration、hot code swapping……,还有一些常用的精巧的数据结构实现,所有的东西很主流;其次是一流的代码组织结构和干净简洁的代码风格,尤其是整个系统的命名恰到好处,可读性相当高,很kiss,这种风格值得学习和模仿;第三是通过阅读源码可以感受到作者严谨的作风和卓越的能力,可以给自己增加动力,树立榜样的力量。 另一方面,要达到这些目标难度很高,必须要制定详细的计划和采取一定有效的方法。 对于这么大的一个系统,想一口气知晓全部的细节是不可能的,并且nginx 各个部分的实现之间关系紧密,不可能做到窥一斑而知全身,合适的做法似乎

nginx设置rewrite规则

Nginx 设置rewrite规则 Windows下环境为wamp ,在wamp 环境下,设置rewite规则时,很是简单,只需要打开Apache配置中的rewrite规则,项目中使用rewrite规则时只需创建.htaccess文件,在文件中编写规则,Apache会自动进行解析,但是在linux下则有些不一样。 Linux下环境若是lamp,则和wamp下是相同的,但当环境为lnmp时,需要注意进行如下配置方法: 根据所安装的环境情况,如果环境是lnmp集成环境,在配置rewrite规则时,因为集成环境,在安装完毕后,在安装的目录/usr/local/nginx/conf下,会生成一个文件“wordparss”,这个文件中是专门用于写rewrite规则所用,你可以在这个文件中书写rewrite规则,nginx 的rewrite规则与Apache的规则基本是相同的,只是在文件中书写的方法不同,wordpaess 问件中默认是有一个规则的,如: 利用location加载访问路径,“/”,指代由访问路径的根目录开始, 用if对加载的路径$request_filename 进行验证: 1 、-f 和!-f 用来判断文件是否存在 2、-d 和!-d 用来判断目录是否存在 3 、-e 和!-e 用来判断文件或目录是否存在 4、-x 和!-x 用来判断文件是否可执行 Flag标记: 1、last 相当于Apache里的[L]标记,表示完成rewrite 2、break 终止匹配, 不再匹配后面的规则 3、redirect 返回302临时重定向地址栏会显示跳转后的地址 4、permanent 返回301永久重定向地址栏会显示跳转后的地址 因为在lnmp集成环境下要配置虚拟域名是可以进行自动生成的,生成后会在/usr/local/nginx/conf/vhost 下生成一个以虚拟域名的名字的文件,如:lin_hp.its.conf,而所对应的rewrite规则最好在与域名相对应的配置文件中进行配置,这样不会说,如果有多个域名时,他们所对应的rewrite规则不同,在公共的wordpress文件中配置引起冲突,所配置的方法与在wprdpress文件中是相同的,如:

Android源代码结构分析

目录 一、源代码结构 (2) 第一层次目录 (2) bionic目录 (3) bootloader目录 (5) build目录 (7) dalvik目录 (9) development目录 (9) external目录 (13) frameworks目录 (19) Hardware (20) Out (22) Kernel (22) packages目录 (22) prebuilt目录 (27) SDK (28) system目录 (28) Vendor (32)

一、源代码结构 第一层次目录 Google提供的Android包含了原始Android的目标机代码,主机编译工具、仿真环境,代码包经过解压缩后,第一级别的目录和文件如下所示: . |-- Makefile (全局的Makefile) |-- bionic (Bionic含义为仿生,这里面是一些基础的库的源代码) |-- bootloader (引导加载器),我们的是bootable, |-- build (build目录中的内容不是目标所用的代码,而是编译和配置所需要的脚本和工具) |-- dalvik (JAVA虚拟机) |-- development (程序开发所需要的模板和工具) |-- external (目标机器使用的一些库) |-- frameworks (应用程序的框架层) |-- hardware (与硬件相关的库) |-- kernel (Linux2.6的源代码) |-- packages (Android的各种应用程序) |-- prebuilt (Android在各种平台下编译的预置脚本) |-- recovery (与目标的恢复功能相关) `-- system (Android的底层的一些库)

操作系统课程设计内存管理

内存管理模拟 实验目标: 本实验的目的是从不同侧面了解Windows 2000/XP 对用户进程的虚拟内存空间的管理、分配方法。同时需要了解跟踪程序的编写方法(与被跟踪程序保持同步,使用Windows提供的信号量)。对Windows分配虚拟内存、改变内存状态,以及对物理内存(physical memory)和页面文件(pagefile)状态查询的API 函数的功能、参数限制、使用规则要进一步了解。 默认情况下,32 位Windows 2000/XP 上每个用户进程可以占有2GB 的私有地址空间,操作系统占有剩下的2GB。Windows 2000/XP 在X86 体系结构上利用二级页表结构来实现虚拟地址向物理地址的变换。一个32 位虚拟地址被解释为三个独立的分量——页目录索引、页表索引和字节索引——它们用于找出描述页面映射结构的索引。页面大小及页表项的宽度决定了页目录和页表索引的宽度。 实验要求: 使用Windows 2000/XP 的API 函数,编写一个包含两个线程的进程,一个线程用于模拟内存分配活动,一个线程用于跟踪第一个线程的内存行为,而且要求两个线程之间通过信号量实现同步。模拟内存活动的线程可以从一个文件中读出要进行的内存操作,每个内存操作包括如下内容: 时间:操作等待时间。 块数:分配内存的粒度。 操作:包括保留(reserve)一个区域、提交(commit)一个区域、释放(release)一个区域、回收(decommit)一个区域和加锁(lock)与解锁(unlock)一个区域,可以将这些操作编号存放于文件。保留是指保留进程的虚拟地址空间,而不分配物理 存储空间。提交在内存中分配物理存储空间。回收是指释放物理内存空间,但在虚拟地址空间仍然保留,它与提交相对应,即可以回收已经提交的内存块。释放是指将物理存储和虚拟地址空间全部释放,它与保留(reserve)相对应,即可以释放已经保留的内存块。 大小:块的大小。 访问权限:共五种,分别为PAGE_READONLY,PAGE_READWRITE ,PAGE_EXECUTE,PAGE_EXECUTE_READ 和PAGE EXETUTE_READWRITE。可以将这些权限编号存放于文件中跟踪线程将页面大小、已使用的地址范围、物理内存总量,以及虚拟内存总量等信息显示出来。

手把手教你开发Nginx模块

手把手教你开发Nginx模块 前面的哪些话 关于Nginx模块开发的博客资料,网上很多,很多。但是,每篇博客都只提要点,无法"step by step"照着做,对于初次接触Nginx开发的同学,只能像只盲目的蚂蚁瞎燥急!该篇文章没有太多技术深度,只是一步一步说明白Nginx模块的开发过程。 开发环境搭建 工欲善其事,必先利其器。个人推荐Eclipse CDT 作为IDE,原因很简单,代码提示与补全功能很全,完胜Codeblock这类...相信与否,试过就知道。 在ubuntu下搭建开发环境: 安装GCC编译器 apt-get install build-essential 安装pcre/openssl/zlib开发库 apt-get install libpcre3-dev apt-get install libssl-dev apt-get install libzip-dev 必需安装nginx核心模块依赖的pcre,openssl,zilib开发库 安装JRE/Eclipse CDT apt-get install openjdk-8-jre wget http://ftp.yz.yamagata-u.ac.jp/pub/eclipse//technology/epp/downloads/release/neon/R/eclipse-cpp-neon-R-linux-gtk-x86_64.tar.gz && tzr -xzvf eclipse-cpp-neon-R-linux-gtk-x86_64.tar.gz 下载nginx源码 wget https://www.360docs.net/doc/a19778083.html,/download/nginx-1.10.1.tar.gz && tar -xzvf nginx-1.10.1.tar.gz 配置CDT Build Environment 添加变量,值Nginx src下各模块路径,用冒号分隔,例如: /root/Workspace/nginx-1.10.1/src/core:/root/Workspace/nginx-1.10.1/src/event:/root/Workspace/nginx-1.10.1/src/http:/root/Workspace/nginx-1.10.1/src/mail:/root/Workspace/n ginx-1.10.1/src/stream:/root/Workspace/nginx-1.10.1/src/os/unix 添加环境变量,创建C项目时自动作为-I选项 image image Nginx模块编译流程 Nginx使用configure脚本分析环境,自动生成objs结果。哪么configure如何编译第三方模块?答案是--add-module指定第三方模块目录,并将目录存为$ngx_addon_dir环境变量。执行$ngx_addon_dir/config脚本,读取模块配置。在config中的环境变量分为2种:小写的本地环境变量,大写的全局环境变量。例如: ngx_addon_name=ngx_http_mytest_module

Android USB 驱动分析

Android USB 驱动分析 一、USB驱动代码架构和使用 1、代码简介 USB驱动代码在/drivers/usb/gadget下,有三个文件:android.c, f_adb.c, f_mass_storage.c;g_android.ko 是由这三个文件编译而来,其中android.c 依赖于 f_adb.c 和 f_mass_storage.c(这两个文件之间无依赖关系)。 可在android.c中看到: static int __init android_bind_config(struct usb_configuration *c) { struct android_dev *dev = _android_dev; int ret; printk(KERN_DEBUG "android_bind_config\n"); ret = mass_storage_function_add(dev->cdev, c, dev->nluns); if (ret) return ret; return adb_function_add(dev->cdev, c); } 2、驱动使用 要使USB mass storage连接到主机: 打开/sys/devices/platform/usb_mass_storage/lun0/file文件,向 file文件写入一个存储 设备的路径,例如/dev/block/vold/179:0 (major:minor)路径; 这里的usb_mass_storage根据实际应用可以改的,由 platform_device_register函数的参数决 定。 例如: static struct platform_device fsg_platform_device = { .name = "usb_mass_storage", .id = -1, }; static void __init tegra_machine_init(void) { .... (void) platform_device_register(&fsg_platform_device); .... }

nginx配置解析详解(一)

nginx配置解析详解(一) 现在针对nginx源码分析的blog和文章已经很多了,之前我也看过不少,大家的分析都很不错。太多重复的内容就不写了,主要想针对在我分析代码和查阅blog的过程中,发现的一些比较晦涩或者某些细节有待展开讨论的地方,给出我的自己理解和看法,希望跟大家交流和学习。 使用的nginx版本是nginx-1.0.6,我最开始看的代码是0.7.62,新的版本在功能和稳定性上做了很多的工作。在分析的时候,我尽量简单明了,不太重要的地方一带而过,具体地大家可以去读代码。相对复杂或者晦涩的地方,将详细展开。 首先我们从配置文件开始,下面的分析是建立在网友对nginx的配置文件结构有大概熟悉为前提,这样才可以很好的理解代码。这里有必要提醒一点:原始代码目录中 ngx_modules这个结构,是找不到它的定义和初始化,要看到它,你必须执行configure,make,在原来的代码目录下会出现一个objs文件夹,里面的3个文件ngx_auto_config.h,ngx_auto_headers.h,ngx_modules.c,需要在建source insight工程时也包含进去,这样有利于我们把握整个代码结构。有意思的是,nginx的configure文件是作者手工写的,里面有许多管理代码工程的方法,有时间的话,也是值得学习下的。 1.ngx_cycle_t *ngx_init_cycle(ngx_cycle_t *old_cycle); 配置文件的解析相关的处理主要在ngx_init_cycle函数中被调用。既然如此,我们就先说说ngx_init_cycle函数吧。 它需要一个参数类型为ngx_cycle_t *,返回值也是一个ngx_cycle_t*,与此同时我们注意到参数名为old_cycle,那么这个函数的作用是啥呢?很明显是由old得到一个new。其中ngx_cycle_t的结构保存一些全局的配置和信息。 这个函数具体作用将在reconfig(重读配置文件)的时候得到体现,可以理解为old_cycle 是当前正在使用的配置信息,当配置文件做了某些修改之后,ngx_init_cycle通过old_cycle 中的一些数据,对new_cycle进行一些设置,在经过进一步的配置解析之后,就可以得到一个new cycle。 2.char *ngx_conf_parse(ngx_conf_t *cf, ngx_str_t *filename) 当我们使用sourceinsight查看这个函数的调用情况时,会发现调用它的地方很多。其实,入口点就在ngx_init_cycle中对ngx_conf_parse调用,后面的所有的调用可以看作是在此之后的递归调用。为什么会是这个样子呢?原因在于nginx是一边读取配置信息,一边解析执行相关的处理,具体一点讲,就是“读一行,执行一行”,一行的定义在这里是指以分号或者是“{”和“}”等结尾的一行,例如:我们解析到http {},我们就调用针对httpblock的处理,在处理的时候我们又会碰到server {},自然就会调用server block的处理。。。以此类推!。

Android 串口编程原理和实现方式附源码

提到串口编程,就不得不提到JNI,不得不提到JavaAPI中的文件描述符类:。下面我分别对JNI、以及串口的一些知识点和实现的源码进行分析说明。这里主要是参考了开源项目android-serialport-api。 串口编程需要了解的基本知识点:对于串口编程,我们只需对串口进行一系列的设置,然后打开串口,这些操作我们可以参考串口调试助手的源码进行学习。在Java中如果要实现串口的读写功能只需操作文件设备类:即可,其他的事都由驱动来完成不用多管!当然,你想了解,那就得看驱动代码了。这里并不打算对驱动进行说明,只初略阐述应用层的实现方式。 (一)JNI: 关于JNI的文章网上有很多,不再多做解释,想详细了解的朋友可以查看云中漫步的技术文章,写得很好,分析也很全面,那么在这篇拙文中我强调3点: 1、如何将编译好的SO文件打包到APK中?(方法很简单,直接在工程目录下新建文件夹libs/armeabi,将SO文件Copy到此目录即可) 2、命名要注意的地方?(在编译好的SO文件中,将文件重命名为:lib即可。其中是编译好后生成的文件) 3、MakeFile文件的编写(不用多说,可以直接参考package/apps目录下用到JNI的相关项目写法) 这是关键的代码: [cpp]view plaincopy

(二):

文件描述符类的实例用作与基础机器有关的某种结构的不透明句柄,该结构表示开放文件、开放套接字或者字节的另一个源或接收者。文件描述符的主要实际用途是创建一个包含该结构的或。这是API的描述,不太好理解,其实可简单的理解为:就是对一个文件进行读写。 (三)实现串口通信细节 1) 建工程:SerialDemo包名:org.winplus.serial,并在工程目录下新建jni和libs两个文件夹和一个org.winplus.serial.utils,如下图: 2) 新建一个类:SerialPortFinder,添加如下代码: [java]view plaincopy 1.package org.winplus.serial.utils; 2. 3.import java.io.File; 4.import java.io.; 5.import java.io.IOException; 6.import java.io.LineNumberReader; 7.import java.util.Iterator; 8.import java.util.Vector; 9. 10.import android.util.Log; 11. 12.public class SerialPortFinder { 13. 14.private static final String TAG = "SerialPort"; 15.

nginx虚拟主机和文件服务器的配置

Nginx文件服务器和虚拟主机的配置 https://www.360docs.net/doc/a19778083.html,的配置文件: 1.游戏服务器: server { listen 80; server_name https://www.360docs.net/doc/a19778083.html,; index index.html index.htm index.php; root /data/web/fc/game3w/releases1/public; location ~ .*\.php$ { include fcgi.conf; fastcgi_pass 127.0.0.1:10080; fastcgi_index index.php; expires off; } access_log /data/logs/https://www.360docs.net/doc/a19778083.html,.log access; } 2.客户端的配置: server { listen 80; server_name https://www.360docs.net/doc/a19778083.html,; index index.html index.htm index.php; root /data/web/fc/resource; charset utf-8; #expires 2h; location ~* .svn$ { return 404; } location ~ .*\.swf$ { expires 365d; } location ~ .*\.css$ { expires 365d; } location ~ .*\.xml$ { expires 365d;

} location ~ .*\.js$ { expires 365d; } location ~ .*\.jpg$ { expires 365d; } location ~ .*\.gif$ { expires 365d; } location ~ .*\.png$ { expires 365d; } location ~ .*\.mp3$ { expires 365d; } location ~ .*\.game$ { expires 365d; } location ~ .*\.lib$ { expires 365d; } access_log off; } 3.文件服务器的配置: server { listen 9000; server_name 192.168.26.8; location / { autoindex on; autoindex_exact_size off; autoindex_localtime on; index index.html index.htm index.php; root /data/server/trunk/bin/logs/; allow all; } }

App工程结构搭建:几种常见Android代码架构分析

App工程结构搭建:几种常见Android代码架构分析 关于Android架构,因为手机的限制,目前我觉得也确实没什么大谈特谈的,但是从开发的角度,看到整齐的代码,优美的分层总是一种舒服的享受的。 从艺术的角度看,其实我们是在追求一种美。 本文先分析几个当今比较流行的android软件包,最后我们汲取其中觉得优秀的部分,搭建我们自己的通用android工程模板。 1. 微盘 微盘的架构比较简单,我把最基本,最主干的画了出来: 第一层:com.sina.VDisk:com.sina(公司域名)+app(应用程序名称) 。 第二层:各模块名称(主模块VDiskClient和实体模块entities)第三层:各模块下具体子包,实现类。 从图中我们能得出上述分析中一个最简单最经典的结构,一般在应用程序包下放一些全局的包或者类,如果有多个大的模块,可以分成多个包,其中包括一个主模块。 在主模块中定义基类,比如BaseActivity等,如果主模块下还有子模块,可以在主模块下建立子模块相应的包。说明一点,有的时候如果只有一个主模块,我们完全可以省略掉模

块这一层,就是BaseActivity.java及其子模块直接提至第二层。 在实体模块中,本应该定义且只定义相应的实体类,供全局调用(然而实际情况可能不是这样,后面会说到)。在微盘应用中,几乎所有的实体类是以xxx+info命名的,这种命名也是我赞成的一种命名,从语义上我觉得xxxModel.java这种命名更生动更真实,xxxModel给我一种太机械太死板的感觉,这点完全是个人观点,具体操作中以个人习惯为主。还有一点,在具体的xxxInfo,java中有很多实体类中是没有get/set的方法,而是直接使用public的字段名。这一点,我是推荐这种方式的,特别是在移动开发中,get/set方法很多时候是完全没有必要的,而且是有性能消耗的。当然如果需要对字段设置一定的控制,get/set方法也是可以酌情使用的。 2. 久忆日记 相比于微盘的工程结构,久忆日记的结构稍微复杂了一些。如下图: 1).第一层和前面微盘一样的. 2).第二层则没有模块分类,直接把需要的具体实现类都放在下面,主要日记的一些日记相关的Activity。 3).第二层的实体包命令为model包,里面不仅存放了实体类

内存管理(操作系统)操作系统课程设计

河南城建学院 《操作系统》课程设计说明书 设计题目:存储管理 专业:计算机科学与技术 指导教师:邵国金 班级:0814121 学号:081412112 姓名: 同组人: 计算机科学与工程学院 2015 年1 月9日

前言 本课程设计是编制页面置换算法FIFO、LRU、LFU、NUR和OPT的模拟程序,并模拟其在内存的分配过程。同时根据页面走向,分别采用FIFO、LRU、LFU、NUR和OPT算法进行页面置换,统计命中率;同时系统可以随意设置当前分配给作业的物理块数。 系统运行时,任意输入一个页面访问序列,可以设定不同的页面置换算法和物理块数,输出其页面淘汰的情况,计算其缺页次数和缺页率。系统结束后,比较同一个页面访问序列,可以得出在不同的页面置换算法和物理块数的情况下,其产生的缺页次数和缺页率。 使用FIFO算法,由于测试数据相同的页面比较少,所以采用FIFO算法时,需要置换的页面多,比较繁琐,没有优化效果,所以FIFO算法性能不好。使用LRU的算法,此组数据显示LRU的算法使用比较繁琐,总的来说,NUR、LFU、LRU 算法介于FIFO和OPT之间。通过系统模拟得出,OPT算法的性能高,LRU、NUR、LRU算法的性能次之,FIFO的算法性能最差,较少应用;由于OPT算法在实际上难于实现,所以实际应用一般用LRU算法。 本程序实现了操作系统中页式虚拟存储管理中缺页中断理想型淘汰算法,该算法在访问串中将来再也不出现的或是在离当前最远的位置上出现的页淘汰掉。这样,淘汰掉该页将不会造成因需要访问该页又立即把它调入的现象。该程序能按要求随机确定内存大小,随机产生页面数,进程数,每个进程的页数,给进程分配的页数等,然后运用理想型淘汰算法对每个进程进行计算缺页数,缺页率,被淘汰的序列等功能。

nginx-0.8.38源码探秘

nginx-0.8.38源码探秘 先推荐几个研究nginx源码的好网址: https://www.360docs.net/doc/a19778083.html,/kenbinzhang/category/603177.aspx https://www.360docs.net/doc/a19778083.html,/p/nginxsrp/wiki/NginxCodeReview https://www.360docs.net/doc/a19778083.html,/langwan/blog/category/%D4%B4%C2%EB%B7%D6%CE%F6 网上分析nginx源码的文章很多,但感觉分析的不够具体和完整,而且都是比较老的nginx版本。本源码分析基于nginx-0.8.38版本,力求做到更具体和更完整,这是一种自我学习,希望和对此有兴趣的朋友一起探讨,有不正确的地方,也请各位指正。 那么一切从main开始吧! ngx_get_options函数是main调用的第一个函数,比较简单,它负责分析命令行参数,将相应的值赋给对应的全局变量,其中: 1.ngx_prefix表示nginx的路径前缀,默认为/usr/local/nginx; 2.ngx_conf_file表示nginx配置文件的路径,默认为 /usr/local/nginx/conf/nginx.conf; 3.ngx_test_config表示是否开启测试配置文件,如配置文件的语法是否正确,配置文件是否可正确打开。 ngx_time_init函数格式化nginx的日志时间,包括 ngx_cached_err_log_time,ngx_cached_http_time, ngx_cached_http_log_time,ngx_cached_time。主要操作在ngx_time_update 内,先获取系统当前时间,与之前保存的时间比较(注意slot),如果已经过

Nginx系列讲解

Nginx系列 一信号与配置 一、Nginx与信号 Nginx支持平滑重启,相比于Apache,修改了配置文件后可以不需要先停止程序,再重新启动。 1、启动 nginx –c nginx.conf 其中,-c nginx.conf可以省略不写。如果省略,则默认加载安装目录下的conf子目录中的nginx.conf。 2、停止 停止的方式有很多种,kill时传入不同的信号来结束或者平滑重启。Nginx的进程号记录在Pid文件中,Pid文件的位置可以在conf/nginx.conf中找到。如下图: 当然,也可以根据 ps –ef | grep nginx 来查找Nginx的进程号。我们可以通过kill命令来结束Nginx。 从容停止Nginx: kill –QUIT Nginx进程ID 或 kill – QUIT /usr/local/nginx/logs/nginx.pid 快速停止Nginx: kill –TERM Nginx进程ID 或

kill – TERM /usr/local/nginx/logs/nginx.pid 或 kill –INT Nginx进程ID 或 kill – INT /usr/local/nginx/logs/nginx.pid 强制停止Nginx: kill –9 Nginx进程ID 或 kill -9 /usr/local/nginx/logs/nginx.pid 或 pkill -9 nginx 3、重启 如果修改了Nginx的配置文件,想要重启Nginx。同样可以使用kill命令来传递信号。不过,在此之前,我强烈建议先检查并测试配置文件是否正确。 测试配置文件: nginx –t –c conf/nginx.conf 若提示unknow directive *** in conf/nginx.conf:55. Configuration file conf/nginx.conf test failed,则证明在第55行的***是非法的,需要修改。 若提示the configuration file conf/nginx.conf syntax is ok. Configuration file conf/nginx.conf test is successful,则证明配置文件测试通过,可以重启Nginx了。 平滑重启Nginx: kill –HUP Nginx进程ID 或

最全的Android源码目录结构详解

最全的Android源码目录结构详解 Android 2.1 |-- Makefile |-- bionic (bionic C库) |-- bootable (启动引导相关代码) |-- build (存放系统编译规则及generic等基础开发包配置) |-- cts (Android兼容性测试套件标准) |-- dalvik (dalvik JAVA虚拟机) |-- development (应用程序开发相关) |-- external (android使用的一些开源的模组) |-- frameworks (核心框架——java及C++语言) |-- hardware (部分厂家开源的硬解适配层HAL代码) |-- out (编译完成后的代码输出与此目录) |-- packages (应用程序包) |-- prebuilt (x86和arm架构下预编译的一些资源) |-- sdk (sdk及模拟器) |-- system (底层文件系统库、应用及组件——C语言) `-- vendor (厂商定制代码) bionic 目录 |-- libc (C库) | |-- arch-arm (ARM架构,包含系统调用汇编实现) | |-- arch-x86 (x86架构,包含系统调用汇编实现) | |-- bionic (由C实现的功能,架构无关) | |-- docs (文档) | |-- include (头文件) | |-- inet (?inet相关,具体作用不明) | |-- kernel (Linux内核中的一些头文件) | |-- netbsd (?nesbsd系统相关,具体作用不明) | |-- private (?一些私有的头文件) | |-- stdio (stdio实现) | |-- stdlib (stdlib实现) | |-- string (string函数实现) | |-- tools (几个工具) | |-- tzcode (时区相关代码) | |-- unistd (unistd实现) | `-- zoneinfo (时区信息) |-- libdl (libdl实现,dl是动态链接,提供访问动态链接库的功能)|-- libm (libm数学库的实现,) | |-- alpha (apaha架构) | |-- amd64 (amd64架构) | |-- arm (arm架构) | |-- bsdsrc (?bsd的源码)

相关文档
最新文档