原文：http://blog.csdn.net/tianhai110/article/details/6369762

用例图主要用来描述 用户、需求、系统功能单元 之间的关系。它展示了一个外部用户能够观察到的系统功能模型图。

【用途】：帮助开发团队以一种可视化的方式理解系统的功能需求。

原文：http://blog.csdn.net/tianhai110/article/details/6361338

序列图主要用于展示对象之间交互的顺序。
序列图将交互关系表示为一个二维图。纵向是时间轴，时间沿竖线向下延伸。横向轴代表了在协作中各独立对象的类元角色。类元角色用生命线表示。当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线。
消息用从一个对象的生命线到另一个对象生命线的箭头表示。箭头以时间顺序在图中从上到下排列。

原文：http://blog.csdn.net/tianhai110/article/details/6339565

在UML类图中，常见的有以下几种关系：泛化（Generalization），实现（Realization），关联（Association），聚合（Aggregation），组合（Composition），依赖（Dependency）。

原文链接： Everyday GIT With 20 Commands Or So 翻译： 伯乐在线 - cjpan
译文链接： http://blog.jobbole.com/54184/ （下文在原译文基础上有修正补充）

原文（英）最后更新时间：Last updated 2013-02-15 15:53:17 UTC

这些命令分四种类型：①不需要和其他开发者协作的独立开发者，会经常用到 git init、git show branch、git commit 等命令；②需要和其他人协作的开发者，会常用到 git clone、git push、git pull、git format patch；③在项目中负责接收其他开发者发来更新的核心开发者，会常用到 git am、git pull、git format patch、git revert、git push；④ 代码仓库管理员常用 git daemon、git shell ……

对于任何想做提交的人来说，甚至对于某位单独工作的人来说，【个人开发者（单独开发）】部分命令都是必不可少的。如果你和别人一起工作，你也会需要【个人开发者（参与者）】部分列出的命令。

除了上述的部分，担当【集成人员】角色的人需要知道更多命令。【代码库管理】命令帮助系统管理员负责管理，以及向git代码库提交内容。

原文：http://www.cnblogs.com/1-2-3/archive/2010/07/18/git-commands.html

Git 是一个很强大的分布式版本控制系统。它不但适用于管理大型开源软件的源代码，管理私人的文档和源代码也有很多优势。

参考：
内核工具 – Sparse 简介
http://en.wikipedia.org/wiki/Sparse

Sparse (Semantic Parser) 是内核代码静态分析工具, 能够帮助我们找出代码中的隐患.

参考：APUE读书笔记 之 标准I/O库

本章以stream(区别开STREAMS)为中心，讲解了UNIX的标准I/O库。

stream的核心是FILE结构。打开一个stream时，fopen返回一个FILE对象指针。该FILE结构包括：用于实际I/O的文件描述符，指向该流缓冲区的指针，缓冲区的长度，当前缓冲区的字符，以及出错标志等等。

FILE结构定义在/usr/include/stdio.h中。

1

typedef struct _IO_FILE FILE;

_IO_FILE结构定义在/usr/include/libio.h中。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

struct _IO_FILE {
int _flags; /* High-order word is _IO_MAGIC; rest is flags. */
#define _IO_file_flags _flags
/* The following pointers correspond to the C++ streambuf protocol. */
/* Note: Tk uses the _IO_read_ptr and _IO_read_end fields directly. */
char* _IO_read_ptr; /* Current read pointer */
char* _IO_read_end; /* End of get area. */
char* _IO_read_base; /* Start of putback+get area. */
char* _IO_write_base; /* Start of put area. */
char* _IO_write_ptr; /* Current put pointer. */
char* _IO_write_end; /* End of put area. */
char* _IO_buf_base; /* Start of reserve area. */
char* _IO_buf_end; /* End of reserve area. */
/* The following fields are used to support backing up and undo. */
char *_IO_save_base; /* Pointer to start of non-current get area. */
char *_IO_backup_base; /* Pointer to first valid character of backup area */
char *_IO_save_end; /* Pointer to end of non-current get area. */
struct _IO_marker *_markers;
struct _IO_FILE *_chain;
int _fileno;
#if 0
int _blksize;
#else
int _flags2;
#endif
_IO_off_t _old_offset; /* This used to be _offset but it's too small. */
#define __HAVE_COLUMN /* temporary */
/* 1+column number of pbase(); 0 is unknown. */
unsigned short _cur_column;
signed char _vtable_offset;
char _shortbuf[1];
/* char* _save_gptr; char* _save_egptr; */
_IO_lock_t *_lock;
#ifdef _IO_USE_OLD_IO_FILE
};

参考：
Linux 内核引导参数简介
内核文档 Documentation/kernel-parameters.txt

概述

内核引导参数大体上可以分为两类：一类与设备无关，另一类与设备有关。与设备有关的引导参数多如牛毛，需要阅读内核中的相应驱动程序源码以获取其能够接受的引导参数。比如，如果想知道可以向 AHA1542 SCSI 驱动程序传递哪些引导参数，那么就查看 drivers/scsi/aha1542.c 文件，一般在前面 100 行注释里就可以找到所接受的引导参数说明。大多数参数是通过”__setup(... , ...)“函数设置的，少部分是通过”early_param(... , ...)“函数设置的，逗号前的部分就是引导参数的名称，后面的部分就是处理这些参数的函数名。

原文：《Linux内核修炼之道》精华分享与讨论（21）——二分法与printk()

人生就是一个茶几，上面摆满了杯具。内核也是一个大茶几，不过它上面的杯具是一个个的bug。确定bug什么时候被引入是一个很关键的步骤，在这个定位bug的过程中，不论有意或无意，都会很自然地用到二分查找的方法。

原文参考：《Linux内核修炼之道》精华分享与讨论（19）——不稳定的内核API
linux内核文档：Documentation/stable_api_nonsense.txt

开源社区正以极快的速度向内核中添加新功能，同时又在努力让修补bug的步伐跟上去，放慢开发速度看上去是不太可能的：首先Linux不能在技术上落后，否则就会失去要求越来越苛刻的商业用户；其次是因为Linux需要推动开发者社区的发展，不断增加新功能可以使开发者不感到厌倦，否则他们就可能转移到其它项目，另外也能在现有开发者年老或退出的时候吸引新人才。

在这样的快节奏下，内核开发人员一旦在当前的接口中找到bug，或者更好的实现方式，他们就会很快的去修改当前的接口，这就意味着，函数名可能会改变，结构体可能被扩充或者删减，函数的参数也可能发生改变。一旦接口被修改，内核中使用这些接口的地方需要同时得到修正，这样才能保证所有的部分继续正常工作。