linux 2.6源代码情景分析笔记之进程2
能被独立调度的每个执行上下文都必须拥有自己的进程描述符。进程和进程描述符之间有严格的对应关系，使用32位进程描述符地址标识，进程描述符指针指向这些地址，内核对进程的大部分引用是通过进程描述符指针进行的。
可以使用pid（进程标识符）来标记进程，存放在字段pid中，PID被顺序编号，新创建的进程PID通常是前一个进程的PID加一。
#define PID_MAX_DEFAULT 0x8000
一个线程租中的所有线程使用和该线程组的领头线程（thread group leader）相同的PID，也就是该组中第一个轻量级进程的PID,被存入进程描述符的tgid字段中。getpid()系统调用返回当前进程的tgid值而不是pid的值，因此一个多线程应用的所有线程共享相同的PID。绝大多数进程都属于一个线程组，包含单一的成员；线程组领头线程其tgid的值与pid的相同，因而getpid(）系统调用对这类进程所其的作用和一般进程是一样的。
对每个进程来说，linux把两个不同的数据结构紧凑地存放在一个单独为进程分配的存储区域内：一个内核态的进程堆栈，另一个是紧挨进程描述符的小数据结构thread_info，叫做线程描述符，这块存储区域的大小通常为8192个字节（两个页框）。内核让这8k空间占据连续的两个页框并让第一个页框的起始地址是2^13的倍数。当几乎没有可用的动态内存空间时，就会很难找到这样的两个连续页框，因为空闲空间可能存在大量碎片。内核态的进程访问处于内核数据段的栈，这个栈不同于用户态的进程所用的栈。因为内核控制路径使用很少的栈，因此只需要几千个字节的内核态堆栈。使用task和thread_info字段使thread_info结构与task_struct结构互相关联。
esp寄存器是cpu栈指针，用来存放栈顶单元的地址。栈起始于末端，并朝这个内存区开始的方向增长。从用户态刚切换到内核态之后，进程的内核栈总是空的，因此，esp寄存器指向这个栈的顶端。一旦数据写入堆栈，esp的数值就递减。（thread_info结构是52个字节长）
union thread_union {
struct thread_info thread_info;
unsigned long stack[THREAD_SIZE/sizeof(long)];
};
使用以上联合结构表示一个进程的线程描述符和内核栈。
struct thread_info {
struct task_struct *task; /* main task struct
相关文档：
1. HCI层协议概述：
HCI提供一套统一的方法来访问Bluetooth底层。如图所示：
从图上可以看出，Host Controller Interface(HCI) 就是用来沟通Host和Module。Host通常就是PC， Module则是以各种物理连接形式（USB,serial,pc-card等）连接到PC上的bluetooth Dongle。
在Host这一端：application,SDP,L2cap等协议 ......
例一：发送Signaling Packet：
Signaling Command是2个Bluetooth实体之间的L2CAP层命令传输。所以得Signaling Command使用CID 0x0001.
多个Command可以在一个C-frame（control frame）中发送。
如果要直接发送Signaling Command.需要建立SOCK_RAW类型的L2CAP连接Socket。这样才有机会自己填充Command Code，Identi ......
内核使用的基本数据类型主要有： int ： 标准的C语言整数类型 u32 ： 32位整数类型 pid_t ： 特定内核对象pid的类型 在不同CPU体系结构上，C语言的数据类型所占用的空间是不一样的。在x86系列结构下，数据类型占用的字节数如下表所示： arch char short int long ptr ......
CHM格式是在MS下比较流行的一种文档格式，据说是MS的东西。以前在Linux下要看CHM文档很烦很烦。经常有编码不对，格式支持错误什么的。
以前常用方法如：用xchm、ChmSee或者Firefox的CHM Reader插件。当然也能解决一大部分问题。
现在正式推荐一种CHM浏览器：Gnochm，Gnochm基于Gtk+，运行快速，对中文支持良好，支持全文� ......
由于Linux不是中国人开发的，开发过程中也不是以中文为母语，虽有中文语言包，在软件兼容性上出现中文乱码也在所难免。我抽取网络上前人的经验，结合自己的理解，将他们加以总结，希望对后来者有所帮助。
1、html文件乱码；
&nbs ......
