花了点时间把svnbook看了遍，对于svn有了个比较好的认识。svn info时，修订版和最后修改的修订版总是让我感觉很困惑。要搞明白这个需要对下面几个关键字有所了解。

HEAD：版本库中的最新版本。

COMMITED：文件最后提交生成的版本号。

PREV：文件倒数第二次提交生成的版本号。

BASE：目录签出或者签入生成的版本号。

HEAD、COMMITED和PREV比较好理解，BASE比较难于理解。假设一个目录下有两个文件configure.ac和Makefile.am，第一次将它们check out出来时，会生成一个新的revision，这个便是BASE了。此时使用svn info configure.ac/Makefile.am可以发现它们的修订版是一样的，但是最后修改的修订版不同。这里的修订版对应其实就是BASE，而最后修改的修订版则是COMMITED。插一句，很多人很容易误解为啥修订版号和最后修改的修订版号不一致。

若将configure.ac修改并check in，这个时候会生成一个新的revision，configure.ac的BASE和COMMITED的值相当。而svn info Makefile.am，发现它的BASE和COMMITED没有改变。svn up一下，发现Makefile.am的BASE会变成最新的，和configure.ac相同。

签出代码库。

显示修订版（BASE）和最后修改的修订版（COMMITED）。

修改Makefile.am并签入看看。

svn update一下看看。

svn一个版本库的revision是全局的，不管是在trunk还是branch，也不管使用merge合并代码还是消除修改，签入和签出都会生成一个新的revision。当项目中一个文件签入时会导致别的文件的BASE暂时低于HEAD，但是一旦update，二者将保持一致。

unset LANGUAGE
export LANG="en"
cd /home/kingsoft
mkdir distcc
cd distcc

rpm包用：rpm -ivh ...
bz2包用：tar -xvf ...
进入distcc解压后的目录
./configure && make && make install
mkdir /usr/lib/distcc
mkdir /usr/lib/distcc/bin
cd /usr/lib/distcc/bin
ln -s /usr/local/bin/distcc gcc
ln -s /usr/local/bin/distcc cc
ln -s /usr/local/bin/distcc g++
ln -s /usr/local/bin/distcc c++

进入ccache解压目录
./configure && make && make install

mkdir /Data
mkdir /Data/Cache
mkdir /Data/Cache/CCache
cd /Data/Cache
touch /var/log/distccd.log

vim ~/.bash_profile
把 /usr/lib/distcc/bin 加到PATH
并添加下面内容
## ----- Distcc -----
#
DISTCC_HOSTS="localhost 192.168.1.1"
DISTCC_VERBOSE=1
DISTCC_LOG="/var/log/distcc.log"
export DISTCC_HOSTS PATH DISTCC_VERBOSE DISTCC_LOG
#
## ----- End -----

## ----- Ccache -----
#
# export CCACHE_DISABLE=1
CCACHE_DIR=/Data/Cache/CCache
CCACHE_LOGFILE=/Data/Cache/CCache.log
CCACHE_PREFIX="distcc"
CC="ccache gcc"
CXX="ccache g++"
export CCACHE_DIR CCACHE_LOGFILE CCACHE_PREFIX CC CXX
#
## ----- End -----

vim /etc/rc.local
distccd --daemon --allow 10.20.0.0/16

==========================================
启动监控：distccd --daemon --allow 10.20.0.0/16
查看监控：distccmon-text 1

Nagle算法的基本定义是任意时刻，最多只能有一个未被确认的小段。 所谓“小段”，指的是小于MSS尺寸的数据块，所谓“未被确认”，是指一个数据块发送出去后，没有收到对方发送的ACK确认该数据已收到。

举个例子，比如之前的blog中的实验，一开始client端调用socket的write操作将一个int型数据(称为A块)写入到网络中，由于此时连接是空闲的（也就是说还没有未被确认的小段），因此这个int型数据会被马上发送到server端，接着，client端又调用write操作写入‘\r\n’（简称B块），这个时候，A块的ACK没有返回，所以可以认为已经存在了一个未被确认的小段，所以B块没有立即被发送，一直等待A块的ACK收到（大概40ms之后），B块才被发送。整个过程如图所示：

这里还隐藏了一个问题，就是A块数据的ACK为什么40ms之后才收到？这是因为TCP/IP中不仅仅有nagle算法，还有一个ACK延迟机制 。当Server端收到数据之后，它并不会马上向client端发送ACK，而是会将ACK的发送延迟一段时间（假设为t），它希望在t时间内server端会向client端发送应答数据，这样ACK就能够和应答数据一起发送，就像是应答数据捎带着ACK过去。在我之前的时间中，t大概就是40ms。这就解释了为什么'\r\n'(B块)总是在A块之后40ms才发出。

如果你觉着nagle算法太捣乱了，那么可以通过设置TCP_NODELAY将其禁用 。当然，更合理的方案还是应该使用一次大数据的写操作，而不是多次小数据的写操作。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/historyasamirror/archive/2011/05/15/6423235.aspx

库文件是一个包含了编译后代码、数据的文件，用于与程序其他代码连编，它可以使得程序模块化、编译速度更快，并且易于更新。库文件分为三种（实质为两种，在随后两句话有解释）：静态库（在程序之前就已经装载进其中了）、共享库（在程序启动之时加载进去，在程序直接共享）、动态加载库（dynamically loaded，DL）（在程序运行中任何时候都可以被加载进程序中使用，事实上DL并非是一个完全不同的库类型，共享库可以用作DL而被动态加载（静态库在Linux貌似无法用dlopen加载）。注意有些人使用dynamically linked libraries (DLLs)来指代共享库，有些人使用DLL这个词来形容任何可以被用作DL的库文件，这个请区分对待。

在具体使用中，我们应该多使用共享库，这使得用户可以独立于使用该库文件的程序而更新库。DL的确非常有用，但有时候我们可能并不需要那些灵活性，而对于静态库，由于更新起来实在费劲，我们一般不使用。

2.静态库的建立

静态库就是一堆普通的目标文件（object file），习惯上静态库以.a为后缀，这是使用ar命令生成的。静态库允许用户不用重新编译代码就可以链接程序，以节省重新编译的时间，其实这个时间已经在强大的机器配置和快速的编译器中显得微不足道了，这个常常用来提供程序而不是源代码。速度上，静态ELF（Executable and Linking Format）库文件比共享库或者动态加载库快1%-5%，但实际上常常因为其他因素而并不一定快。

我们写主文件prog.c：

  1: #include
  2: void ctest1(int *);
  3: void ctest2(int *);
  4:
  5: int main()
  6: {
  7:    int x;
  8:    ctest1(&x);
  9:    printf("Valx=%d\n",x);
 10:
 11:    return 0;
 12: }
 13: 然后写这两个函数的实现：

ctest1.c

  1: void ctest1(int *i)
  2: {
  3:    *i=5;
  4: }       ctest2.c

  1: void ctest2(int *i)
  2: {
  3:    *i=100;
  4: }我们首先编译这两个函数实现的源文件：

gnuhpc@gnuhpc-desktop:~/MyCode/lib/statics$ gcc -Wall -c ctest1.c ctest2.c
gnuhpc@gnuhpc-desktop:~/MyCode/lib/statics$ ls
ctest1.c  ctest1.o  ctest2.c  ctest2.o  prog.c

然后创建静态库libctest.a：

gnuhpc@gnuhpc-desktop:~/MyCode/lib/statics$ ar -cvq libctest.a ctest1.o ctest2.o

a - ctest1.o
a - ctest2.o

我们查看一下这个库中的文件：

gnuhpc@gnuhpc-desktop:~/MyCode/lib/statics$ ar -t libctest.a
ctest1.o
ctest2.o

此时我们可以编译我们的程序了，注意-l选项，后边的参数是去掉lib和.a的部分，并且需要放在要编译的文件名之后，否则会报错。：

gnuhpc@gnuhpc-desktop:~/MyCode/lib/statics$ gcc -o test prog.c -L./ –lctest
gnuhpc@gnuhpc-desktop:~/MyCode/lib/statics$ ls
ctest1.c  ctest1.o  ctest2.c  ctest2.o  libctest.a  prog.c  test
gnuhpc@gnuhpc-desktop:~/MyCode/lib/statics$ ./test
Valx=5

3.共享库的建立

共享库是在程序启动时加载的库文件。当共享库加载完毕后所有启动的起来的程序都将使用新的共享库。在创建共享库之前，还需要了解一些知识：

命名规则：
每一个共享库都有一个soname，一般都形如libname.so.versionNumber，其中versionNumber每当接口发生改变时都要增加，一个完全的soname的前缀应该是它所在目录，在一个实际系统中，一个完整的soname只是共享库文件的real name的符号链接。程序运行时在内部列出所需的共享库时使用的就是soname。
每一个共享库也有一个real name，这是包含实际代码的文件名，real name使用soname为前缀，并且在后边添加一些信息，一般都形如soname.MinorNumber.ReleaseNumber。 最后的releaseNumber可有可无。这个是生成共享库时实际文件的名称。
同时，在编译器要求使用一个共享库时使用的名字称为linker name，一般都是去掉版本号的soname，用于gcc中-lname这样的选项的编译。
这几个名字的关系：你在创建实际库文件中指定libreadline.so.3.0为real name ，并且使用符号链接创建soname ->libreadline.so.3和linker name-> /usr/lib/libreadline.so。
放置位置：
GNU标准推荐将所有默认的库安装在/usr/local/lib，这指的是开发者源代码默认的位置。
FHS指出大多数的库文件应该放在/usr/lib，而启动所需的库则应该放在/lib中，而非系统库应该放在/usr/local/lib。这指的是发行版默认的位置，这两个标准并没有矛盾。
共享库的主要有三个步骤：

创建目标代码。
创建库。
使用符号链接创建默认版本的共享库（可选）。
现在我们举个例子来说明，首先我们编译源代码，使用-fPIC选项生成共享库所需的位置独立代码（position-independent code (PIC)）：

gnuhpc@gnuhpc-desktop:~/MyCode/lib/shared$ gcc -Wall -fPIC -c *.c
gnuhpc@gnuhpc-desktop:~/MyCode/lib/shared$ ls
ctest1.c  ctest1.o  ctest2.c  ctest2.o  prog.c  prog.o

然后我们创建库文件：

gnuhpc@gnuhpc-desktop:~/MyCode/lib/shared$ gcc -shared -Wl,-soname,libctest.so.1 -o libctest.so.1.0   *.o
gnuhpc@gnuhpc-desktop:~/MyCode/lib/shared$ ls
ctest1.c  ctest1.o  ctest2.c  ctest2.o  libctest.so.1.0  prog.c  prog.o

-shared选项指明生成共享目标文件，-W1（注意是小写L而不是一）指明传入链接器的参数，在此我们设定了该库的soname为libctest.so.1，-o则指明了生成的目标库文件为libctest.so.1.0（这个就是real name）。

最后创建所需的符号链接：

gnuhpc@gnuhpc-desktop:~/MyCode/lib/shared$ sudo mv libctest.so.1.0 /usr/local/lib/libctest.so.1.0
gnuhpc@gnuhpc-desktop:~/MyCode/lib/shared$ sudo ln -sf /usr/local/lib/libctest.so.1.0 /usr/local/lib/libctest.so.1
gnuhpc@gnuhpc-desktop:~/MyCode/lib/shared$ sudo ln -sf /usr/local/lib/libctest.so.1.0 /usr/local/lib/libctest.so

创建的libctest.so就是上面所谓linker name，用于编译时-lctest选项。

创建的libctest.so.1就是soname，我们在上边说过程序在运行时需要这个名字的符号链接。

此时我们的共享库就建好了，接着我们编译程序：

gnuhpc@gnuhpc-desktop:~/MyCode/lib/shared$ gcc -Wall -L/usr/local/lib prog.c -lctest -o prog
gnuhpc@gnuhpc-desktop:~/MyCode/lib/shared$ ls
ctest1.c  ctest1.o  ctest2.c  ctest2.o  prog  prog.c  prog.o

我们编译完毕，该库并不会包含在可执行文件中，只有在执行时来会动态加载进来。我们可以通过ldd列出一个可执行程序所有的依赖，在我的系统中还找不到/usr/local/bin的路径：

gnuhpc@gnuhpc-desktop:~/MyCode/lib/shared$ ldd prog
    linux-gate.so.1 =>  (0x00a5c000)
    libctest.so.1 => not found
    libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x00a6f000)
    /lib/ld-linux.so.2 (0x00451000)

此时，运行会报找不到库的错误：

gnuhpc@gnuhpc-desktop:~/MyCode/lib/shared$ ./prog
./prog: error while loading shared libraries: libctest.so.1: cannot open shared object file: No such file or directory

我们可以将所需库的路径加入到系统路径中，有三种方法可以完成：

A.在/etc/ld.so.conf中加入所在路径，然后执行ldconfig配置链接器运行时绑定配置。你也可以创建一个文件，将路径写入，然后使用ldconfig –f filename将配置写入。
B.修改LD_LIBRARY_PATH环境变量（Linux下，AIX下为LIBPATH），在其中添加路径。若你直接在.bashrc文件中配置则重启后不失效，否则在shell中设置重启后失效。
我们使用A方法中的-f选项：

gnuhpc@gnuhpc-desktop:~/MyCode/lib/shared$ vi libctest.conf
gnuhpc@gnuhpc-desktop:~/MyCode/lib/shared$ sudo ldconfig -f libctest.conf
gnuhpc@gnuhpc-desktop:~/MyCode/lib/shared$ ./prog
Valx=5
gnuhpc@gnuhpc-desktop:~/MyCode/lib/shared$ ldd prog
    linux-gate.so.1 =>  (0x00f6f000)
    libctest.so.1 => /usr/local/lib/libctest.so.1 (0x005d9000)
    libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x00718000)
    /lib/ld-linux.so.2 (0x001e6000)

其中libctest.conf中写入路径：/usr/local/lib。程序运行正常。

4.动态加载库的使用

动态加载库是在非程序启动时动态加载进入程序的库，这对于实现插件或动态模块有很大的帮助。在Linux中，动态加载库的形式并不特殊，它使用上述两种程序库，使用提供的API在程序运行时动态加载。注意，在不同平台上动态加载库的API并不相同，所以可能会有移植问题出现。

我们可以通过nm命令先查看一下我们创建的库里面有哪些symbol（可以理解为函数方法）供我们使用：

gnuhpc@gnuhpc-desktop:~/MyCode/lib$ nm /usr/local/lib/libctest.so
00001f18 a _DYNAMIC
00001ff4 a _GLOBAL_OFFSET_TABLE_
         w _Jv_RegisterClasses
00001f08 d __CTOR_END__
00001f04 d __CTOR_LIST__
00001f10 d __DTOR_END__
00001f0c d __DTOR_LIST__
000005a0 r __FRAME_END__
00001f14 d __JCR_END__
00001f14 d __JCR_LIST__
00002014 A __bss_start
         w __cxa_finalize@@GLIBC_2.1.3
00000540 t __do_global_ctors_aux
00000420 t __do_global_dtors_aux
00002010 d __dso_handle
         w __gmon_start__
000004d7 t __i686.get_pc_thunk.bx
00002014 A _edata
0000201c A _end
00000578 T _fini
000003a0 T _init
00002014 b completed.7021
000004dc T ctest1
000004ec T ctest2
00002018 b dtor_idx.7023
000004a0 t frame_dummy
000004fc T main
         U printf@@GLIBC_2.0

这个命令对静态库和共享库都支持，第二列为symbol类型，小写字母表示符号是本地的，大写字母表示符号是全局（外部）的，几个常见的字母含义如下：T为代码段普通定义，D为已初始化数据段，B为未初始化数据段，U为未定义（用到该符号但是没有在该库中定义）。

我们创建ctest.h：

  1: #ifndef CTEST_H
  2: #define CTEST_H
  3:
  4: #ifdef __cplusplus
  5: extern "C" {
  6: #endif
  7:
  8: void ctest1(int *);
  9: void ctest2(int *);
 10:
 11: #ifdef __cplusplus
 12: }
 13: #endif
 14:
 15: #endif这里使用extern C是为了使得该库既可以用于C语言又可以用于C++。

我们动态加载库进来：progdl.c

  1: #include
  2: #include
  3: #include "ctest.h"
  4:
  5: int main(int argc, char **argv)
  6: {
  7:    void *lib_handle;
  8:    double (*fn)(int *);
  9:    int x;
 10:    char *error;
 11:
 12:    lib_handle = dlopen("/usr/local/lib/libctest.so", RTLD_LAZY);
 13:    if (!lib_handle)
 14:    {
 15:       fprintf(stderr, "%s\n", dlerror());
 16:       exit(1);
 17:    }
 18:
 19:    fn = dlsym(lib_handle, "ctest1");
 20:    if ((error = dlerror()) != NULL) 
 21:    {
 22:       fprintf(stderr, "%s\n", error);
 23:       exit(1);
 24:    }
 25:
 26:    (*fn)(&x);
 27:    printf("Valx=%d\n",x);
 28:
 29:    dlclose(lib_handle);
 30:    return 0;
 31: }里面的方法解释如下：

void * dlopen(const char *filename, int flag); 
若filename为绝对路径，那么dlopen就会试图打开它而不搜索相关路径，否则就现在环境变量LD_LIBRARY_PATH处搜索，然后在/etc/ld.so.cache以及/lib和/usr/lib搜索。flag我们只解释两个常用的选项：若为RTLD_LAZY则表示在动态库执行时解决未定义符号问题，而RTLD_NOW则表示在dlopen返回前解决未定义符号问题。当你调试时你应该用RTLD_NOW，这个时候若存在未解决的引用程序还可以继续进行。另外，RTLD_NOW选项可能会使打开库的这个操作稍微慢一点，但是以后寻找函数时就会快一点。注意，若程序库相互依赖则应该按依赖顺序依次载入，比如X依赖Y，那么要先载入Y然后再载入X。返回的是一个句柄，若失败则返回null.

char *dlerror(void);
报告任何上一次对加载库操作的错误。两次调用期间若有操作错误则第二次会报告， 否则第二次则返回null——它报告完错误就等待下一个错误的发生，上一次错误的情况一旦报告就不再提及。

void *dlsym(void *handle, const char *symbol);
寻找对应symbol的函数方法，handle就是dlopen返回的句柄。一般如下使用：
  1:  dlerror(); /* clear error code */
  2:  s = (actual_type) dlsym(handle, symbol_being_searched_for);
  3:  if ((err = dlerror()) != NULL) {
  4:   /* handle error, the symbol wasn't found */
  5:  } else {
  6:   /* symbol found, its value is in s */
  7:  }int dlclose(void *handle);
关闭一个动态加载库。当一个动态库被加载多次时，你需要用同样次数dlclose该动态库才可以deallocated.

我们编译该代码gcc -g -rdynamic -o progdl progdl.c -ldl，即可得到可执行文件（其中-g选项是为了gdb调试所用），其中的库为动态加载后又关闭的。我们使用gdb看一下代码：

(gdb) b main
Breakpoint 1 at 0x804878d: file progdl.c, line 12.
(gdb) r
Starting program: /home/gnuhpc/MyCode/lib/dynamic/progdl

Breakpoint 1, main (argc=1, argv=0xbffff4a4) at progdl.c:12
12       lib_handle = dlopen("/usr/local/lib/libctest.so", RTLD_LAZY);
(gdb) f
#0  main (argc=1, argv=0xbffff4a4) at progdl.c:12
12       lib_handle = dlopen("/usr/local/lib/libctest.so", RTLD_LAZY);
(gdb) s
13       if (!lib_handle)
(gdb) n
19       fn = dlsym(lib_handle, "ctest1");
(gdb)
20       if ((error = dlerror()) != NULL) 
(gdb)
26       (*fn)(&x);
(gdb)
27       printf("Valx=%d\n",x);
(gdb) p x
$1 = 5
(gdb) p fn
$2 = (double (*)(int *)) 0x28c4dc

可以看到fn获得了ctest1的地址。

参考文献：

http://www.yolinux.com/TUTORIALS/LibraryArchives-StaticAndDynamic.html

http://www.linuxjournal.com/article/3687

http://www.dwheeler.com/program-library/Program-Library-HOWTO/

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/gnuhpc/archive/2010/12/20/6086143.aspx

ldd查看应用程序链接了哪些动态库。

nm列出目标文件中包含的符号信息。

size列出各个段的大小及总的大小。

strings列出文件中的字符串。

readelf读取elf文件的完整结构。

objdump导出目标文件的相关信息（elf文件相关工具的源头）。

gdb对文件的执行过程进行调试分析，设置断点(b)、单步执行(n)、函数调用追踪(bt)、反汇编(disassemble)。

strace跟踪程序中的系统调用及信号处理信息。

LD_DEBUG通过设置这个环境变量，可以方便的看到 loader 的加载过程（包括库的加载，符号解析等过程），使用【LD_DEBUG=help 可执行文件路径】可查看使用帮助。

LD_PRELOAD环境变量指定的共享库会被预先加载，如果出现重名的函数，预先加载的函数将会被调用，如在预先加载的库中包含自定义的puts函数，则在执行程序时将使用自定义版本的puts函数，而不是libc库中的puts函数。

proc文件系统中包含进程的地址空间映射关系，具体查看/proc/进程id/maps文件的内容。

valgrind工具对可执行程序文件进行内存检查（还有cache模拟、调用过程跟踪等功能），以避免内存泄露等问题。

addrline将可执行文件中的地址转换为其在源文件中对应的位置（文件名：行号）。

处理器总处于以下状态中的一种：
１、内核态，运行于进程上下文，内核代表进程运行于内核空间；
２、内核态，运行于中断上下文，内核代表硬件运行于内核空间；
３、用户态，运行于用户空间。

用户空间的应用程序，通过系统调用，进入内核空间。这个时候用户空间的进程要传递很多变量、参数的值给内核，内核态运行的时候也要保存用户进程的一些寄存器值、变量等。所谓的“进程上下文”，可以看作是用户进程传递给内核的这些参数以及内核要保存的那一整套的变量和寄存器值和当时的环境等。

硬件通过触发信号，导致内核调用中断处理程序，进入内核空间。这个过程中，硬件的一些变量和参数也要传递给内核，内核通过这些参数进行中断处理。所谓的“中断上下文”，其实也可以看作就是硬件传递过来的这些参数和内核需要保存的一些其他环境（主要是当前被打断执行的进程环境）。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/eroswang/archive/2007/11/28/1905830.aspx

作者联系方式：李先静 <xianjimli at hotmail dot com>

更新时间：2007-6-21

在正式进入Marvell-linux研究之前，我们介绍一点背景知识，让没有手机开发经验的朋友有个概念。

1.       基带(BaseBand)

基带是传统手机中最重要的功能，它直接与无线网络交互，负责信号的发送和接收。所有编码/解码和网络协议处理都是它负责的，这一部分也是最复杂，涉及专利最多的部分。所幸的是，大部分处理都集成在芯片里了，对于一般手机设计来说，至少在软件方面是不用太关心的。

我们知道，交变电流在流经导体时会产生无线电波，无线电波可以经过空间传播出去，这就是无线发送的原理。而无线电波又可以让导体产生电流，电流信号可恢复为与发送时的一致信号，这就是无线接收的原理。

在无线电设备中，这里的导体就是天线，天线的长度是有要求的，它一般不能小于波长的一半，像耳朵能听声音频率范围是20Hz～20KHz，最敏感的部分在2500赫兹到3000赫兹之间。因为波长x频率=光速，以3000赫兹的无线电波为例，它对应的波长是100公里，如果直接收/发这种电波，那么天线长度至少要50公里，我们当然不可能在手机上安装一个50公里长的天线，怎么办呢？

要缩短天线的长度，只能提高电波的频率。发送时，把低频信号调制在高频信号上再发送出去，接收时，先得到高频信号，然后从中解调出低频信号。这里高频信号称为载波，一般GSM手机使用1800M或900M的载波，而CDMA使用800M或1900M的载波。当然这里的频率指的是中心频率，信号本身要占一定的带宽，而且为了避免干扰，发送和接收所用的频率也不一样，以900M的载波来看，接收频率为925M-960M，发送频率为880M-915M。

高频信号是真正在空间中传播的无线信号，对高频信号的处理也就是所谓的射频(RF) 信号处理，高频信号让天线变短了，这是它的好处，同时也带来了副作用，因为它的波长太短，它可能把印刷板上的导线都当作天线，在上面产生感应电流，原本两根无关的导线，现在变得关系暧昧，加上无线电波的反射互相影响，使其中充满太多不确定因素，导致射频电路设计非常复杂。按照温伯格的《系统化思维导论》里的说法，这是一个典型的中数系统，即不能采用小数系统中那样的简化，又不能采用大数系统中的概率统计。

手机的功率比较小，它不能直接与卫星建立通信，而是与基站(BS)之间通信，基站呈蜂窝状布置，所以以前称手机为蜂窝电话。

现在的手机都是数字信号，即使音频信号也要进行数字编码之后才能传递，任何通信都有一套通信协议，手机和基站之间的通信当然也不例外，多个手机共享基站，信道的建立，手机在基站之间的切换，如此等等，还有很多复杂的情况，所以整套协议非常复杂。

多个手机共享一个基站，如何共享，这就是所谓的多址问题。常见的有频分多址（FDMA）、时分多址（TDMA）和码分多址（CDMA）。在2G中通常使用频分多址（FDMA）和时分多址（TDMA）的组合，而在3G中使用码分多址（CDMA）。

2.       应用处理器(AP)

AP从逻辑上讲是一个独立的东西，在物理上可以独立于基带处理器，也可以从属于基带处理器。如果使用Marvell的Monahans系列芯片，那么可以肯定AP是独立于基带处理器的。

AP的功能是运行应用程序，我们常说的MMI就是在这上面运行，一般手机设计公司的主要工作就是开发这些应用程序。一个典型软件(linux平台)的分层视图如下图所示：

在Marvell-linux这个系列中，我们关注的主要是linux kernel中与平台相关的部分。

3.       BB与AP的桥梁

既然像电话这种通信类应用程序是在AP上跑的，而通信功能又是在BB上实现的，那么就一定会存在一个连接AP和BB的通道。

最常见的连接方式就是串口，在linux下，也就是tty设备。在AP这边，用AT命令控制BB，来实现打电话和发短信等功能，在3GPP的《AT command set for User Equipment (UE)》文档中定义标准的AT命令，各个模组厂家为了增加功能，在上面都做了些扩展，在使用AT时，要参考模组厂家的手册。

AT命令是文本格式的，它经过串口发送到BB。它控制BB来完成打电话和发短信等传统功能没有问题，但是要通过BB无线上网(如GPRS)，就遇到麻烦了，因为上网的数据是二进制的，如果和AT命令混在一起从串口传输，那就会乱成一团了。

为了解决AT命令和二进制数据共享串口的问题，3GPP制定了一个称为多路复用的协议，它把一个物理串口虚拟成多个逻辑上的串口。应用程序使用各自独立的虚拟串口而互不干扰。

有人会问GPRS数据和AT命令是通过多路复用协议经串口在AP和BB之间传递的，那么打电话时的语音数据呢，是不是也是走条通道呢？答案是否，因为那样做效率太低了，所以对于下行语音数据，BB解码后直接送到speaker，对上行的语音数据，从MIC采样/处理后，直接通过BB发送出去。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/absurd/archive/2007/06/21/1661231.aspx