wekey 的个人空间

本文关键字: IPTV⁹⁹, 监测⁴⁵, 运营商⁶, 网络²³, 监测系统⁵, 融合², 电信⁵, 有线电视¹, 宽带², Qos⁸, ITU¹⁵, 测试³⁰, VOD⁴, 流媒体³, 信令¹, IP⁶, 服务器¹, DSL⁵, 国际标准化组织¹, 机顶盒⁶, 广域网¹, H.264¹, 中国电信², 电信网¹

摘要　在IPTV业务的实际运营中，如何保证和监测端到端的业务质量是运营商关注的主要问题。本文首先介绍了IPTV业务质量的定义和业务质量模型，并从运营商角度提出了业务质量监测的需求。之后介绍了目前IPTV质量监测领域的技术、标准和产业发展状况，最后提出了在IPTV业务网络中部署端到端监测系统的技术方案。

1、引言

随着近几年在业务融合、技术、标准以及商业模式等方面的摸索，IPTV业务在中国开始逐步成熟并进入到规模商用阶段。IPTV作为一种电信级业务，要达到大规模应用需要有效的业务质量保障。由于IPTV是电视类的媒体业务，用户希望得到如同有线电视的服务水平，包括频道切换速度、节目的图像质量、播放的流畅性等。而传统的宽带业务质量监测侧重于数据链路层和网络层的监测，无法直接反映用户对IPTV业务的主观感受，因此不能满足IPTV质量监测的需求。

本文针对现有监测方案的不足，提出了一种采用分布式部署与集中管理相结合的监测方案，该方案具有监测功能丰富、可扩展性强等优点，可满足现阶段IPTV业务质量监测的需要。

2、业务质量定义及模型

业务质量（quality of service，QoS）术语并不是针对IPTV的，在很多电信业务中都提出QoS要求及相关的QoS保障技术。在ITU-T E.800[1]标准中，QoS被定义为“反映用户对业务使用满意程度的服务性能的综合效果”。对传统电信业务而言，QoS通常指网络性能，尤其是网络传输性能。而由于IPTV是一种上层应用的业务，传统的QoS无法满足对最终用户感受的评估，因此目前业界往往采用体验质量（quality of experience，QoE）一词来描述面向最终用户应用的业务质量。QoE在ITU-T P.10/G.100[2]中被定义为“最终用户对使用的应用或业务的总体主观可接受程度”，可见QoE相比QoS更强调最终用户的业务使用感受。

目前尚无国际规范对IPTV业务质量进行完整定义，国际标准组织ITU正在进行IPTV GSI（global standard initial，全球主动标准）工作，以推动全球IPTV标准化进程。其中暂时还没有对IPTV业务质量进行定义，仍沿用了ITU-T P.10/G.100中对QoE的定义。IPTV GSI也指出，IPTV QoE应该同时包含主观评估质量和客观评估质量两部分内容，前者主要根据人眼视觉系统来评估视频质量，通过主观感受来评估体验质量；后者则可以定义各种客观指标，并采用相应的测试工具进行测量，具体如图1所示。

图1 目前ITU IPTV GSI规定的QoE定义范围

作者比较赞同ITU IPTV GSI目前对IPTV业务质量的定义，在本文中也采用IPTV QoE来表示IPTV业务质量。当然，从运营商的角度来说不仅仅关心IPTV业务质量定义，更具实际意义的是如何量化IPTV业务质量，如何建立IPTV 业务质量的指标体系以指导现网的质量运维。因此，需要根据IPTV所涉及的技术环节，建立IPTV业务质量的评估模型。

图2参考OSI的7层模型，给出了一种可供参考的IPTV业务质量的参数模型，并展示了与IPTV协议栈之间的对应关系。

图2 IPTV业务质量模型与OSI 7层模型和IPTV协议栈的关系

如图2所示，IPTV QoE的参数模型覆盖了OSI 7层模型的所有层次。其中，客观QoE相关的分层质量对应于IPTV的协议栈中各个协议，各层次的质量参数可以通过采集对应的协议及其字段获得。

具体的，客观QoE包含以下几方面的内容。

●内容质量和业务控制质量：主要指直播频道、时移节目、VOD节目、图片、文字等内容的品质和业务控制的性能指标。例如对于直播频道质量，需要采集和分析媒体编码参数、分辨率参数等；对于业务控制质量，需要采集HTTP和RTSP请求的响应速度、页面数据呈现完整度、组播加入/退出的时延等。

●流媒体质量：主要指流媒体传输层的性能指标，以采用MPEG2 TS协议传输IPTV节目为例，DVB系统测试标准TR 101-290根据各参数对质量影响的程度不同，定义了3个级别，每个级别分别对应一组质量参数，这些参数同样可供采用MPEG2 TS协议的IPTV系统参考，例如需要采集第一级别中的同步错误字段（sync loss）、包识别丢失（PID missing），第二级别中的数据传输错误（transport error）、节目参考时钟抖动错误（PCR，jitter error）等参数。如果采用RTSP作为VOD节目的流控制协议，则要采集RTSP信令参数。

●网络传输层质量：主要指网络传输层相关协议的性能指标，包括TCP/UDP的重传次数，在采用了RTP的情况下，需要监测RTP丢包率、RTP抖动等。

●网络层质量：主要指传统IP网络层的性能指标，根据ITU-T Y.1540[3]建议，主要为IP丢包率、IP包时延、IP包抖动及其相关参数。

●链路层质量：根据不同的链路层类型，需要采集不同的性能指标。由于这个层次的质量保障是面向全业务而不仅仅是IPTV业务，本文不做详述。

主观QoE主要是用户对IPTV业务使用中的主观感受，这些感受是对服务接入速度、内容质量、使用操作便利性等多方面的综合，至少可以包含以下参数：

●开机进入IPTV主界面的速度；

●用户鉴权频道浏览（加入/离开时延）；

●视频内容的清晰度和流畅程度；

●直播频道的切换速度；

●VOD节目进行快进、快退和暂停操作的响应速度；

●业务请求的响应速度、业务内容的完整性等。

3、业务质量监测需求

IPTV业务质量监测应包含两部分，即监控和测试，二者相互关联但又相对独立。其中监控技术主要是面向IPTV运维部门使用，协助IPTV平台及网络运维部门监控网络运行中的质量状态，帮助定位故障和解决问题，因此要求监控技术能够覆盖整个IPTV业务质量领域。测试主要面向IPTV产品研发、性能评估和故障排查等应用，因此测试技术往往针对与IPTV业务质量相关的某一个领域或层面，重点解决某一类问题。

如前所述，IPTV业务质量监控应该覆盖整个IPTV业务领域，是面向IPTV业务的端到端全网监测，具体应满足以下需求。

●满足IPTV业务的7×24 h不间断监测，同时不对正在运营的IPTV系统产生影响。

●监测范围能够覆盖整个IPTV网络的各个环节，并能根据各环节采集的参数进行对比分析。这些环节至少包括：内容头端系统、系统核心平台出口、边缘节点出口、关键网络节点等。

●当IPTV质量发生劣化时，系统能够自动采集质量劣化的技术参数，并作详细记录；能够通过对比分析各节点参数，进行故障点分析和快速定位。

●能够根据采集参数进行平台及服务器的性能分析等。

●能够完成图2中质量模型各层次的分析。

而IPTV业务质量测试主要针对与IPTV业务质量相关的某一个领域或层面，如在实验室进行质量验证或问题和故障发生后进行定位和排障，或针对IPTV某个网元设备进行测试。因此IPTV业务质量测试往往可以借助原来各层面的相关测试工具进行，下面举几个例子。

●内容质量的测试：主要在实验室或内容上线前，采用专门的质量检测工具进行图像质量、伴音质量、字幕质量、元数据质量等的测试，主要针对直播频道、时移节目、VOD节目、图片、文字等内容的品质和业务控制的性能指标。

●流媒体层的测试：主要在系统上线前对流协议的规范性进行测试和验证。

●网络传输层、网络层和链路层质量测试：主要采用与应用无关的专用测试软件或仪表测试目前IPTV承载网络的质量状况。

4、标准及产业链现状

如前所述，IPTV作为一个新兴的融合性业务，目前还没有非常完备的国际规范。虽然包括ITU IPTV GSI、ATIS（alliance for telecommunication industry solution，电信行业解决方案联盟）、IPTV论坛、DSL论坛、DVB（digital video broadcasting，数字视频广播）等多家国际标准化组织已开始相关的标准化推进工作，但目前尚未正式发布。尽管如此，在IPTV业务质量监测的系统架构、参数建议等方面已取得了较大进展。

●ITU IPTV GSI：已经初步完成了IPTV业务质量相关的需求草案和IPTV业务性能监测的草案，目前ITU的相关工作组正在进行后续的工作，计划在2008年底能够成为国际规范。

●ATIS：起步较早，在2006年就开始了IPTV QoS指标体系、IPTV QoE模型等相关的制定工作，计划在2008年完成。

●DSL论坛：主要关注机顶盒侧与业务质量相关的参数定义，目前已经完成了机顶盒数据模型技术报告（DSL Forum TR135）、可应用于机顶盒的终端广域网管理协议技术报告（DSL Forum TR069）等。

在产业链支持方面，尽管还没有完整的IPTV业务质量监测技术标准可供参考，但由于IPTV业务的快速部署和运营商对质量监测需求的迫切，市场上已经有多家测试仪表厂商能够提供IPTV质量监测仪表。如前所述，IPTV业务质量监测包含测试和监控两部分，因此这些仪表也可对应地分为测试和监控两大类。

在测试仪表方面，主要是针对某个层面的专用测试工具，例如美国IneoQuest公司提供的Singulus G1-T系列测试仪表，其主要特征是支持RFC4445定义的MDI指标值，可应用于IPTV数据的模拟、捕捉、数据流监控以及视频质量的分析；思博伦公司提供的IPTV测试解决方案包括宽带网络测试、频道切换测试、频道内容验证等；泰克公司则提供了较为完备的视频质量测试和分析工具，如能够分析H.264编解码参数的MTS4EA，能够测试视频主观质量的PQA仪表等。

在监控系统方面，目前还没有很完备的、能完全满足运营商需求的解决方案。美国JDSU公司提供的QT系列仪表可应用于IPTV直播频道的7×24 h质量监控，监控的内容包括了网络质量、传输层质量等。因此，目前国内的IPTV运营商开始根据运维需求自主或与合作伙伴联合开发IPTV业务质量监测系统。例如中国电信上海研究院就和国内的中创信测合作开发了IPTV业务质量监测系统，该系统已能够支持现网应用的主流IPTV系统，支持从业务层到网络层的端到端业务质量监测。

5、IPTV端到端业务质量监测方案

以下以中国电信上海研究院与中创信测合作开发的IPTV业务质量监测系统为例，介绍IPTV端到端的质量解决方案。该系统是一个独立的分布式系统，叠加在现有IPTV业务网络中，通过部署监测代理或测试探针的方式来获得IPTV业务运行时各个网络节点的相关质量参数数据，并由监测平台进行集中采集、分析和统计，以获得IPTV业务总体质量情况。

值得一提的是，该方案的系统架构与目前ITU IPTV GSI正在制定的IPTV性能监测标准一致，均采用了“分布部署、集中采集”的系统架构，如图3所示，其中PT指监测点。

图3 目前ITU IPTV GSI定义的业务质量系统架构

如图3所示，整个系统主要包括监测管理平台、监测代理。

监测管理平台：负责管理监测代理和采集所有代理上传的监测数据，并执行统计和分析，是整个系统的核心组件。

监测代理：主要完成业务质量参数的采集和上传，根据部署的监测点不同，又可以分为3种工作模式。

●仿真模式：即主动模式，仿真用户的IPTV业务登录、认证及基本业务流程，能够通过预定义的脚本文件，自动进行相关的测试，记录并形成业务质量参数记录文件，上传给监测管理平台所有的性能参数。在图3中，该模式可以部署在PT4和PT5的位置。

●监测模式：即被动模式，通过数据镜像或备份的方式获得用户业务数据，分析质量参数，并记录和上传给监测管理平台所有参数。在图3中，该模式可以部署在PT1、PT2和PT3的位置。

●机顶盒内嵌模式（STB embedded test agent，STB-TA）：在机顶盒内部嵌入测试客户端软件，能够将机顶盒运行中的业务质量参数记录并上传到监测管理平台。在图3中，该模式可以部署在PT1、PT2和PT3的位置。

当然，从系统角度来看，IPTV监测系统在不同的节点所关注的质量是不同的，因此当监测代理工作在不同的模式下或部署在不同的节点时，所采集的质量参数也不尽相同，这里就不详述了。

从整个系统的架构可以看出，上述系统基本覆盖了IPTV端到端各个环节，所采集的参数能够帮助完成图2中质量模型客观QoE各个层面的分析，能够协助IPTV平台及网络运维部门监控网络运行中的质量状态，从而帮助定位故障和解决问题。

6、结束语

IPTV是一个跨广电网、IP网、电信网的复杂应用，其业务质量监测需要综合考虑视音频内容质量、网络质量、用户最终感受等多重因素。本文对IPTV业务质量监测相关技术进行了研究，并提出了IPTV业务质量模型及性能监测的系统框架。

但是对于IPTV运维部门来说，需要一整套IPTV业务质量指标体系，希望能够通过类似主观评测分的等级划分来衡量整个IPTV系统质量，并提供可操作的监测手段。因此，后续还需要研究IPTV业务质量指标体系，量化和评估每个指标对最终用户感受的影响，并研究各业务质量指标的采集方法，从而构建完整的IPTV业务质量监测体系，保证IPTV业务的顺利运营。

参考文献

1　ITU-T E.800.Terms and definitions related to quality of service and network performance including dependability，August 1994

2　ITU-T P.10/G.100.Vocabulary for performance and quality of service，July 2006

3　ITU-T Y.1540.Internet protocol data communication service-IP packet transfer and availability performance parameters，Nov、2007

4　DSL Forum.www.dslforum.org

作者：罗斯青 段保通   来源：电信科学

转载自： zzzppp.cublog.cn

The History of GCC

1984年，Richard Stallman发起了自由软件运动，GNU (Gnu's Not Unix)项目应运而生，3年后，最初版的GCC横空出世，成为第一款可移植、可优化、支持ANSI C的开源C编译器。
GCC最初的全名是GNU C Compiler,之后，随着GCC支持的语言越来越多，它的名称变成了GNU Compiler Collection。
这里介绍的gcc是GCC的前端，C编译器.

警告信息

    -Wall : 显示所有常用的编译警告信息。
    -W    : 显示更多的常用编译警告，如：变量未使用、一些逻辑错误。
    -Wconversion : 警告隐式类型转换。
    -Wshadow : 警告影子变量（在代码块中再次声明已声明的变量)
    -Wcast-qual ：警告指针修改了变量的修饰符。如：指针修改const变量。
    -Wwrite-strings : 警告修改const字符串。
    -Wtraditional : 警告ANSI编译器与传统C编译器有不同的解释。
    -Werror : 即使只有警告信息，也不编译。（gcc默认：若只有警告信息，则进行编译，若有错误信息，则不编译）

C语言标准

你可以在gcc的命令行中通过指定选项来选择相应的C语言标准: 从传统c到最新的GNU扩展C. 默认情况下, gcc使用最新的GNU C扩展.
    -ansi : 关闭GNU扩展中与ANSI C相抵触的部分。
    -pedantic          : 关闭所有的GNU扩展。
    -std=c89           : 遵循C89标准
    -std=c99           : 遵循C99标准
    -std=traditional : 使用原始C
注意：后4个选项可以与-ansi结合使用，也可以单独使用。
可在gcc中使用大量GNU C扩展.

生成特定格式的文件

以hello.c为例子，可以设置选项生成hello.i, hello.s, hello.o以及最终的hello文件：
    hello.c : 最初的源代码文件；
    hello.i : 经过编译预处理的源代码；
    hello.s : 汇编处理后的汇编代码；
    hello.o : 编译后的目标文件，即含有最终编译出的机器码，但它里面所引用的其他文件中函数的内存位置尚未定义。
    hello / a.out : 最终的可执行文件
    (还有.a(静态库文件), .so(动态库文件), .s(汇编源文件)留待以后讨论)

如果你不通过-o指定生成可执行文件名，那么会默认生成a.out. 不指定生成文件名肯能覆盖你上次生成的a.out.

e.g.
$ gcc hello.c
在不给gcc传递任何参数的情况下, gcc执行默认的操作: 将源文件编译为目标文件--> 将目标文件连接为可执行文件(名为a.out) --> 删除目标文件.

-c生成.o文件时，默认生成与源代码的主干同名的.o文件。比如对应hello.c生成hello.o. 但也可在生成目标文件时指定目标文件名(注意同时要给出.o后缀): $ gcc -c -o demo.o demo.c

    $ gcc -Wall -c hello.c              : 生成hello.o
    $ gcc -Wall -c -save-temps hello.c  : 生成hello.i, hello.s, hello.o
    注意-Wall 选项的使用场合：仅在涉及到编译（即会生成.o文件时，用-Wall）  

多文件编译、连接

如果原文件分布于多个文件中：file1.c, file2,c
    $ gcc -Wall file1.c file2.c -o name

若对其中一个文件作了修改，则可只重新编译该文件,再连接所有文件：
    $ gcc -Wall -c file2.c
    $ gcc file1.c file2.o -c name

注意：若编译器在命令行中从左向右顺序读取.o文件，则它们的出现顺序有限制：含有某函数定义的文件必须出现在含有调用该函数的文件之后。好在GCC无此限制。

编译预处理

包含头文件

下面看这个求立方的小程序(阴影语句表示刚开始不存在）:

#include <stdio.h>
#include <math.h>
int main(int argc, char *argv[])
{
  double x = pow (2.0, 3.0);
  printf("The cube of 2.0 is %f\n", x);
  return 0;
}

使用gcc-2.95来编译它(-lm选项在后面的连接选项中有介绍, 这里只讨论头文件的包含问题):
$ gcc-2.95 -Wall pow.c -lm -o pow_2.95
pow.c: In function `main':
pow.c:5: warning: implicit declaration of function `pow'

程序编译成功，但gcc给出警告: pow函数隐式声明。
$ ./pow_2.95
The cube of 2.0 is 1.000000

明显执行结果是错误的，在源程序中引入头文件(#include <math.h>)，消除了错误。

不要忽略Warning信息！它可能预示着，程序虽然编译成功，但运行结果可能有错。故，起码加上"-Wall"编译选项！并尽量修正Warning警告。

搜索路径

首先要理解 #include<file.h>和#include"file.h"的区别:
#include<file.h>只在默认的系统包含路径搜索头文件
#include"file.h"首先在当前目录搜索头文件, 若头文件不位于当前目录, 则到系统默认的包含路径搜索头文件.

UNIX类系统默认的系统路径为：

头文件，包含路径：　/usr/local/include/  or  /usr/include/
库文件，连接路径：　/usr/local/lib/          or  /usr/lib/   

对于标准c库(glibc或其它c库)的头文件, 我们可以直接在源文件中使用#include <file.h>来引入头文件.

如果要在源文件中引入自己的头文件, 就需要考虑下面的问题:

1, 如果使用非系统头文件, 头文件和源文件位于同一个目录, 如何引用头文件呢?
——我们可以简单地在源文件中使用 #include "file.h", gcc将当前目录的file.h引入到源文件. 如果你很固执, 仍想使用#include <file.h>语句, 可以在调用gcc时添加"-I."来将当前目录添加到系统包含路径. 细心的朋友可能会想到: 这样对引用其它头文件会不会有影响? 比如, #include<file.h>之后紧接着一个#include<math.h>, 它能正确引入math.h吗? 答案是: 没有影响. 仍然能正确引用math.h. 我的理解是: "-I."将当前目录作为包含路径的第一选择, 若在当前目录找不到头文件, 则在默认路径搜索头文件. 这实际上和#include"file.h"是一个意思.

2, 对于比较大型的工程, 会有许多用户自定义的头文件, 并且头文件和.c文件会位于不同的目录. 又该如何在.c文件中引用头文件呢?
—— 可以直接在.c文件中利用#include“/path/file.h", 通过指定头文件的路径(可以是绝对路径, 也可以是相对路径)来包含头文件. 但这明显降低了程序的可移植性. 在别的系统环境下编译可能会出现问题. 所以还是利用"-I"选项指定头文件完整的包含路径.

针对头文件比较多的情况, 最好把它们统一放在一个目录中, 比如~/project/include. 这样就不需为不同的头文件指定不同的路径. 如果你嫌每次输入这么多选项太麻烦, 你可以通过设置环境变量来添加路径:
$ C_INCLUDE_PATH=/opt/gdbm-1.8.3/include
$ export C_INCLUDE_PATH
$ LIBRART_PATH=/opt/gdbm-1.8.3/lib
$ export LIBRART_PATH
可一次指定多个搜索路径，":"用于分隔它们，"."表示当前路径，如：
$ C_INCLUDE_PATH=.:/opt/gdbm-1.8.3/include:/net/include
$ LIBRARY_PATH=.:/opt/gdbm-1.8.3/lib:/net/lib
（可以添加多个路径，路径之间用:相隔，.代表当前目录，若.在最前头，也可省略）
当然，若想永久地添加这些路径，可以在.bash_profile中添加上述语句.

3, 还有一个比较猥琐的办法: 系统默认的包含路径不是/usr/include或/usr/local/include么? 我把自己的头文件拷贝到其中的一个目录, 不就可以了么? 的确可以这样, 如果你只想在你自己的机器上编译运行这个程序的话.

前面介绍了三种添加搜索路径的方法，如果这三种方法一起使用，优先级如何呢？
命令行设置　> 环境变量设置　> 系统默认

与外部库连接

有一个例外: libc.a或libc.so (C标准库,它包含了ANSI C所定义的C函数)是不需要你显式连接的, 所有的C程序在运行时都会自动加载c标准库.

除了C标准库之外的库称之为"外部库", 它可能是别人提供给你的, 也可能是你自己创建的(后面有介绍如何创建库的内容).
外部库有两种：(1)静态连接库lib.a
                     (2)共享连接库lib.so

两者的共同点：
    .a, .so都是.o目标文件的集合，这些目标文件中含有一些函数的定义（机器码），而这些函数将在连接时会被最终的可执行文件用到。

两者的区别：
    静态库.a  : 当程序与静态库连接时，库中目标文件所含的所有将被程序使用的函数的机器码被copy到最终的可执行文件中. 静态库有个缺点: 占用磁盘和内存空间. 静态库会被添加到和它连接的每个程序中, 而且这些程序运行时, 都会被加载到内存中. 无形中又多消耗了更多的内存空间.

    共享库.so : 与共享库连接的可执行文件只包含它需要的函数的引用表，而不是所有的函数代码，只有在程序执行时, 那些需要的函数代码才被拷贝到内存中, 这样就使可执行文件比较小, 节省磁盘空间(更进一步，操作系统使用虚拟内存，使得一份共享库驻留在内存中被多个程序使用).共享库还有个优点: 若库本身被更新, 不需要重新编译与它连接的源程序。

静态库

下面我们来看一个简单的例子，计算2.0的平方根（假设文件名为sqrt.c）：

#include <math.h>
#include <stdio.h>
int
main (void)
{
double x = sqrt (2.0);
printf ("The square root of 2.0 is %f\n", x);
return 0;
}

用gcc将它编译为可执行文件：
$ gcc -Wall sqrt.c -o sqrt
编译成功，没有任何警告或错误信息。执行结果也正确。
$ ./sqrt
The square root of 2.0 is 1.414214
下面我们来看看刚才使用的gcc版本：
$ gcc --version
gcc (GCC) 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)

现在我用2.95版的gcc把sqrt.c再编译一次：
$ gcc-2.95 -Wall sqrt.c -o sqrt_2.95
/tmp/ccVBJd2H.o: In function `main':
  sqrt.c:(.text+0x16): undefined reference to `sqrt'
     collect2: ld returned 1 exit status
编译器会给出上述错误信息，这是因为sqrt函数不能与外部数学库"libm.a"相连。sqrt函数没有在程序中定义，也不存在于默认C库 "libc.a"中，如果用gcc-2.95，应该显式地选择连接库。上述出错信息中的"/tmp/ccVBJd2H.o"是gcc创造的临时目标文件，用作连接时用。

使用下列的命令可以成功编译：
$ gcc-2.95 -Wall sqrt.c /usr/lib/libm.a -o sqrt_2.95
它告知gcc:在编译sqrt.c时，加入位于/usr/lib中的libm.a库（C数学库）。

C库文件默认位于/usr/lib, /usr/local/lib系统目录中； gcc默认地从/usr/local/lib, /usr/lib中搜索库文件。（在我的Ubuntu系统中，C库文件位于/urs/lib中。

这里还要注意连接顺序的问题，比如上述命令，如果我改成：
$ gcc-2.95 -Wall /usr/lib/libm.a sqrt.c -o sqrt_2.95
gcc会给出出错信息：
/tmp/cc6b3bIa.o: In function `main':
sqrt.c:(.text+0x16): undefined reference to `sqrt'
collect2: ld returned 1 exit status

正如读取目标文件的顺序，gcc也在命令行中从左向右读取库文件——任何包含某函数定义的库文件必须位于调用该函数的目标文件之后！

指定库文件的绝对路径比较繁琐，有一种简化方法，相对于上述命令，可以用下面的命令来替代：
$ gcc-2.95 -Wall sqrt.c -lm -o sqrt_2.95
其中的"-l"表示与库文件连接，"m"代表"libm.a"中的m。一般而言，"-lNAME"选项会使gcc将目标文件与名为"libNAME.a"的库文件相连。（这里假设使用默认目录中的库，对于其他目录中的库文件，参考后面的“搜索路径”。）

上面所提到的"libm.a"就是静态库文件，所有静态库文件的扩展名都是.a！
$ whereis libm.a
libm: /usr/lib/libm.a /usr/lib/libm.so

正如前面所说，默认的库文件位于/usr/lib/或/usr/local/lib/目录中。其中，libm.a是静态库文件，libm.so是后面会介绍的动态共享库文件。

如果调用的函数都包含在libc.a中（C标准库被包含在/usr/lib/libc.a中，它包含了ANSI C所定义的C函数）。那么没有必要显式指定libc.a：所有的C程序运行时都自动包含了C标准库！（试试 $ gcc-2.95 -Wall hello.c -o hello)。

共享库

正因为共享库的优点，如果系统中存在.so库，gcc默认使用共享库（在/usr/lib/目录中，库文件以共享和静态两种版本存在）。 

运行：$ gcc -Wall -L. hello.c -lNAME -o hello
gcc先检查是否有替代的libNAME.so库可用。   

正如前面所说，共享库以.so为扩展名（so == shared object)。

那么，如果不想用共享库，而只用静态库呢？可以加上 -static选项
$ gcc -Wall -static hello.c -lNAME -o hello
它等价于：
$ gcc -Wall hello.c libNAME.a -o hello

$ gcc-2.95 -Wall sqrt.c -static -lm -o sqrt_2.95_static
$ gcc-2.95 -Wall sqrt.c -lm -o sqrt_2.95_default
$ gcc-2.95 -Wall sqrt.c /usr/lib/libm.a -o sqrt_2.95_a
$ gcc-2.95 -Wall sqrt.c /usr/lib/libm.so -o sqrt_2.95_so

$ ls -l sqrt*
-rwxr-xr-x  1 zp zp  21076 2006-04-25 14:52 sqrt_2.95_a
-rwxr-xr-x  1 zp zp   7604 2006-04-25 14:52 sqrt_2.95_default
-rwxr-xr-x  1 zp zp   7604 2006-04-25 14:52 sqrt_2.95_so
-rwxr-xr-x  1 zp zp 487393 2006-04-25 14:52 sqrt_2.95_static

上述用四种方式编译sqrt.c，并比较了可执行文件的大小。奇怪的是，-static -lm 和 /lib/libm.a为什么有区别？有知其原因着，恳请指明，在此谢谢了！ :)

如果libNAME.a在当前目录，应执行下面的命令：
$ gcc -Wall -L. hello.c -lNAME -o hello
-L.表示将当前目录加到连接路径。

利用GNU archiver创建库

$ ar cr libhello.a hello_fn.o by_fn.o
从hello_fn.o和by_fn.o创建libihello.a，其中cr表示：creat & replace
$ ar t libhello.a
列出libhello.a中的内容，t == table
（也可创建libhello.so）

关于创建库的详细介绍，可参考本blog的GNU binutils笔记

调试

GCC提供-g选项，将调试信息加入到目标文件或可执行文件中。
$ gcc -Wall -g hello.c -o hello
注意：若发生了段错误，但没有core dump，是由于系统禁止core文件的生成！
$ ulimit -c　　，若显示为0，则系统禁止了core dump

解决方法:
$ ulimit -c unlimited　　（只对当前shell进程有效）
或在~/.bashrc　的最后加入： ulimit -c unlimited （一劳永逸）

优化

GCC提供了下列优化选项：
    -O0  : 默认不优化（若要生成调试信息，最好不优化）
    -O1  : 简单优化，不进行速度与空间的权衡优化；   
    -O2  : 进一步的优化，包括了调度。（若要优化，该选项最适合，它是GNU发布软件的默认优化级别；
    -O3  : 鸡肋，兴许使程序速度更慢；
    -funroll-loops  : 展开循环，会使可执行文件增大，而速度是否增加取决于特定环境；
    -Os  : 生成最小执行文件；
一般来说，调试时不优化，一般的优化选项用-O2（gcc允许-g与-O2联用，这也是GNU软件包发布的默认选项），embedded可以考虑-Os。

注意：此处为O！（非0或小写的o,-o是指定可执行文件名）。
检验优化结果的方法：$ time ./prog

time测量指定程序的执行时间，结果由三部分组成：
    real : 进程总的执行时间, 它和系统负载有关(包括了进程调度,切换的时间)
    user: 被测量进程中用户指令的执行时间
    sys  : 被测量进程中内核代用户指令执行的时间

user和sys的和被称为CPU时间.

注意：对代码的优化可能会引发警告信息，移出警告的办法不是关闭优化，而是调整代码。

转载自： zzzppp.cublog.cn

GNU binutils是一组二进制工具集。包括：addr2line   ar   gprof   nm   objcopy   objdump   ranlib   size   strings   strip. 本文归纳他们的常用法。
ar

$ gcc -Wall -c file1.c file2.c file3.c

    不用指定生成.o文件名(默认生成file1.o, file2.o, file3.o)。
    (2) 从.o目标文件创建静态连接库：

$ ar rv libNAME.a file1.o file2.o file3.o

    ar生成了libNAME.a库，并列出库中的文件。
r : 将flie1.o, file2,o, file3.o插入archive，如故原先archive中已经存在某文件，则先将该文件删除。
v : 显示ar操作的附加信息(如被处理的member文件名)
注: 对于BSD系统, 还需要在创建静态库之后创建索引: $ ranlib libNAME.a Linux中不需要这一步(运行它也是无害的).
创建动态库(利用gcc，未用ar)
(1) 生成目标文件

$ gcc -Wall -c -fpic file1.c file2.c file3.c

-fpic: 指定生成的.o目标文件可被重定址. pic是position idependent code的缩写: 位置无关代码.
(2)生成动态库文件

$ gcc -shared -o libNAME.so file1.o file2.o file3.o

一般地, 连接器使用main()函数作为程序入口. 但在动态共享库中没有这样的入口. 所以就要指定-shared选项来避免编译器显示出错信息.
实际上, 上述的两条命令可以合并为下面这条:

$ gcc -Wall -shared -fpic -o libNAME.so file1.c file2.c file3.c

此后，将main函数所在的程序与libNAME.so连接（注意库连接路径和头文件包含路径，以及连接顺序！参考gcc笔记）
至此，与动态库连接的函数编译成了一个可执行文件。貌似成功了，但还差最后一步。如果直接运行该程序，会给出这样的错误信息:

error while loading shared libraries: libhello.so:
cannot open shared object file: No such file or directory

这是因为与动态库连接的程序在运行时，首先将该动态库加载到内存中，而gcc默认加载动态库文件所在目录为/usr/local/lib, /usr/lib。刚才的程序虽然能编译成功，但如果我们自己建立的动态库没有位于默认目录中，则执行时会应为无法找到它而失败。
解决办法：改变加载路径对应的环境变量，然后再执行。

export LD_LIBRARY_PATH=动态库所在目录:$LD_LIBRARY_PATH

查看archive内容

$ ar tv archiveNAME

t : 显示archive中member的内容，若不指定member，则列出所有。
v : 与t结合使用时，显示member的详细信息。
要想进了解ar的详细选项，参考ar的on-line manual
nm

int main(int argc, char *argv[])
{
  hello();
  bye();
  return 0;
}

hello.c:  

void hello(void)
{
  printf("hello!\n");
}

bye.c:

void bye(void)
{
  printf("good bye!\n");
}

    运行下列命令:
$ gcc -Wall -c main.c hello.c bye.c
    gcc生成main.o, hello.o, bye.o三个目标文件(这里没有声明函数原型,加了-Wall,gcc会给出警告)
$ nm main.o hello.o bye.o
结果显示如下:  

main.o:
                 U bye
                 U hello
00000000 T main
hello.o:
00000000 T hello
                 U puts
bye.o:
00000000 T bye
                 U puts

    结合这些输出结果,以及程序代码,可以知道:
    对于main.o, bye和hello未被定义, main被定义了
    对于hello.o, hello被定义了, puts未被定义
    对于bye.o, bye被定义了,puts未被定义
几个值得注意的问题:
    (1)"目标文件"指.o文件, 库文件, 最终的可执行文件
    .o  : 编译后的目标文件，即含有最终编译出的机器码，但它里面所引用的其他文件中函数的内存位置尚未定义.
    (2)如果用nm查看可执行文件, 输出会比较多, 仔细研究输出, 可以对nm用法有更清醒的认识.
    (3)在上述hello.c, bye.c中, 调用的是printf(), 而nm输出中显示调用的是puts(), 说明最终程序实际调用的puts(), 如果令hello.c或bye.c中的printf()使用格式化输出,则nm显示调用printf(). ( 如: printf("%d", 1); )
    关于nm的参数选项,参考on-line manual
objcopy

$ file hello.o hello

    file命令用来判别文件类型, 输出如下:
hello.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
hello:  ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), not stripped
    现在运行objcopy来改变hello的文件类型: 原先它是ELF格式的可执行程序, 现将它转换为srec格式. srec格式文件是Motolora S-Record格式的文件, 主要用来在主机和目标机之间传输数据.

$ objcopy -O srec hello hello_srec
$ file hello.o hello

    file命令结果: hello_srec: Motorola S-Record; binary data in text format
    注意objcopy的格式, "-O"指定输出文件类型; 输入文件名和输出文件名位于命令末尾. 关于objcopy命令的详细选项, 参考on-line manual
objdump

$ objdump -f hello hello_srec

输出如下:
hello:     file format elf32-i386
architecture: i386, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x080482c0
hello_srec:     file format srec
architecture: UNKNOWN!, flags 0x00000000:
start address 0x00000000080482c0
-f : 显示目标文件的头文件概要信息.
生成反汇编代码:

$ objdump -d hello.o

显示如下:
hello.o:     file format elf32-i386
Disassembly of section .text:
00000000 <hello>:
   0:   55                      push   %ebp
   1:   89 e5                   mov    %esp,%ebp
   3:   83 ec 08                sub    $0x8,%esp
   6:   83 ec 0c                sub    $0xc,%esp
   9:   68 00 00 00 00          push   $0x0
   e:   e8 fc ff ff ff          call   f <hello+0xf>
  13:   83 c4 10                add    $0x10,%esp
  16:   c9                      leave
  17:   c3                      ret
    -d : 显示目标文件中机器指令使用的汇编语言. 只反汇编那些应该含有指令机器码的节(显示.text段); 如果用-D, 则反汇编所有节的内容.
    关于objcopy命令的详细选项, 参考on-line manual
readelf

$ readelf -h hello

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                                           ELF32
  Data:                                            2's complement, little endian
  Version:                                        1 (current)
  OS/ABI:                                          UNIX - System V
  ABI Version:                                   0
  Type:                                              EXEC (Executable file)
  Machine:                                        Intel 80386
  Version:                                          0x1
  Entry point address:                       0x80482c0
  Start of program headers:              52 (bytes into file)
  Start of section headers:                 3848 (bytes into file)
  Flags:                                               0x0
  Size of this header:                          52 (bytes)
  Size of program headers:                32 (bytes)
  Number of program headers:          7
  Size of section headers:                  40 (bytes)
  Number of section headers:            34
  Section header string table index:   31
注意: readelf只能用于ELF格式目标文件, 且选项中至少要指定一个(除V, H外)的选项!
gprof

#include <stdio.h>
/* Computes the length of Collatz sequences */
unsigned int step (unsigned int x)
{
     if (x % 2 == 0)
     {
      return (x / 2);
     }
     else
     {
      return (3 * x + 1);
     }
}
unsigned int nseq (unsigned int x0)
{
     unsigned int i = 1, x;
     if (x0 == 1 || x0 == 0)
      return i;
     x = step (x0);
     while (x != 1 && x != 0)
     {
      x = step (x);
      i++;
     }
     return i;
}
int main (void)
{
     unsigned int i, m = 0, im = 0;
     for (i = 1; i < 500000; i++)
     {
      unsigned int k = nseq (i);
      if (k > m)
      {
           m = k;
           im = i;
           printf ("sequence length = %u for %u\n", m, im);
      }
     }
     return 0;
}

    先将collatz.c编译成目标文件collatz.o， gcc通过 -pg选项来打开gprof支持：

$ gcc -Wall -c -pg collatz.c

$ gcc -Wall -pg -o collatz collatz.o

    注意：两条命令都要加 "-pg"选项。前一条命令生成collatz.o目标文件。后一条命令生成可执行文件，该可执行文件中包含了记录函数执行时间的指令。
    生成collatz可执行文件后，现执行它，结果与一般程序的执行无疑。但此时在PWD目录生成一个名为"gmon.out"的文件，gprof通过它来分析程序的执行。
    如果不现执行程序，而直接用gprof来分析它，会提示“gmon.out: No such file or directory”。
    gprof用法：

$ gprof ./collatz

关于gprof更多的描述，参考gprof的on-line manual

Ambiguous operators need parentheses
不明确的运算需要用括号括起
Ambiguous symbol ``xxx``
不明确的符号
Argument list syntax error
参数表语法错误
Array bounds missing
丢失数组界限符
Array size toolarge
数组尺寸太大
Bad character in paramenters
参数中有不适当的字符
Bad file name format in include directive
包含命令中文件名格式不正确
Bad ifdef directive synatax
编译预处理ifdef有语法错
Bad undef directive syntax
编译预处理undef有语法错
Bit field too large
位字段太长
Call of non-function
调用未定义的函数
Call to function with no prototype
调用函数时没有函数的说明
Cannot modify a const object
不允许修改常量对象
Case outside of switch
漏掉了case 语句
Case syntax error
Case 语法错误
Code has no effect
代码不可述不可能执行到
Compound statement missing{
分程序漏掉"{"
Conflicting type modifiers
不明确的类型说明符
Constant expression required
要求常量表达式
Constant out of range in comparison
在比较中常量超出范围
Conversion may lose significant digits
转换时会丢失意义的数字
Conversion of near pointer not allowed
不允许转换近指针
Could not find file ``xxx``
找不到XXX文件
Declaration missing ;
说明缺少"；"
Declaration syntax error
说明中出现语法错误
Default outside of switch
Default 出现在switch语句之外
Define directive needs an identifier
定义编译预处理需要标识符
Division by zero
用零作除数
Do statement must have while
Do-while语句中缺少while部分
Enum syntax error
枚举类型语法错误
Enumeration constant syntax error
枚举常数语法错误
Error directive :xxx
错误的编译预处理命令
Error writing output file
写输出文件错误
Expression syntax error
表达式语法错误
Extra parameter in call
调用时出现多余错误
File name too long
文件名太长
Function call missing )
函数调用缺少右括号
Fuction definition out of place
函数定义位置错误
Fuction should return a value
函数必需返回一个值
Goto statement missing label
Goto语句没有标号
Hexadecimal or octal constant too large
16进制或8进制常数太大
Illegal character ``x``
非法字符x
Illegal initialization
非法的初始化
Illegal octal digit
非法的8进制数字
Illegal pointer subtraction
非法的指针相减
Illegal structure operation
非法的结构体操作
Illegal use of floating point
非法的浮点运算
Illegal use of pointer
指针使用非法
Improper use of a typedefsymbol
类型定义符号使用不恰当
In-line assembly not allowed
不允许使用行间汇编
Incompatible storage class
存储类别不相容
Incompatible type conversion
不相容的类型转换
Incorrect number format
错误的数据格式
Incorrect use of default
Default使用不当
Invalid indirection
无效的间接运算
Invalid pointer addition
指针相加无效
Irreducible expression tree
无法执行的表达式运算
Lvalue required
需要逻辑值0或非0值
Macro argument syntax error
宏参数语法错误
Macro expansion too long
宏的扩展以后太长
Mismatched number of parameters in definition
定义中参数个数不匹配
Misplaced break
此处不应出现break语句
Misplaced continue
此处不应出现continue语句
Misplaced decimal point
此处不应出现小数点
Misplaced elif directive
不应编译预处理elif
Misplaced else
此处不应出现else
Misplaced else directive
此处不应出现编译预处理else
Misplaced endif directive
此处不应出现编译预处理endif
Must be addressable
必须是可以编址的
Must take address of memory location
必须存储定位的地址
No declaration for function ``xxx``
没有函数xxx的说明
No stack
缺少堆栈
No type information
没有类型信息
Non-portable pointer assignment
不可移动的指针（地址常数）赋值
Non-portable pointer comparison
不可移动的指针（地址常数）比较
Non-portable pointer conversion
不可移动的指针（地址常数）转换
Not a valid expression format type
不合法的表达式格式
Not an allowed type
不允许使用的类型
Numeric constant too large
数值常太大
Out of memory
内存不够用
Parameter ``xxx`` is never used
能数xxx没有用到
Pointer required on left side of ->
符号->的左边必须是指针
Possible use of ``xxx`` before definition
在定义之前就使用了xxx（警告）
Possibly incorrect assignment
赋值可能不正确
Redeclaration of ``xxx``
重复定义了xxx
Redefinition of ``xxx`` is not identical
xxx的两次定义不一致
Register allocation failure
寄存器定址失败
Repeat count needs an lvalue
重复计数需要逻辑值
Size of structure or array not known
结构体或数给大小不确定
Statement missing ;
语句后缺少"；"
Structure or union syntax error
结构体或联合体语法错误
Structure size too large
结构体尺寸太大
Sub scripting missing ]
下标缺少右方括号
Superfluous & with function or array
函数或数组中有多余的"&"
Suspicious pointer conversion
可疑的指针转换
Symbol limit exceeded
符号超限
Too few parameters in call
函数调用时的实参少于函数的参数不
Too many default cases
Default太多(switch语句中一个)
Too many error or warning messages
错误或警告信息太多
Too many type in declaration
说明中类型太多
Too much auto memory in function
函数用到的局部存储太多
Too much global data defined in file
文件中全局数据太多
Two consecutive dots
两个连续的句点
Type mismatch in parameter xxx
参数xxx类型不匹配
Type mismatch in redeclaration of ``xxx``
xxx重定义的类型不匹配
Unable to create output file ``xxx``
无法建立输出文件xxx
Unable to open include file ``xxx``
无法打开被包含的文件xxx
Unable to open input file ``xxx``
无法打开输入文件xxx
Undefined label ``xxx``
没有定义的标号xxx
Undefined structure ``xxx``
没有定义的结构xxx
Undefined symbol ``xxx``
没有定义的符号xxx
Unexpected end of file in comment started on line xxx
从xxx行开始的注解尚未结束文件不能结束
Unexpected end of file in conditional started on line xxx
从xxx 开始的条件语句尚未结束文件不能结束
Unknown assemble instruction
未知的汇编结构
Unknown option
未知的操作
Unknown preprocessor directive: ``xxx``
不认识的预处理命令xxx
Unreachable code
无路可达的代码
Unterminated string or character constant
字符串缺少引号
User break
用户强行中断了程序
Void functions may not return a value
Void类型的函数不应有返回值
Wrong number of arguments
调用函数的参数数目错
``xxx`` not an argument
xxx不是参数
``xxx`` not part of structure
xxx不是结构体的一部分
xxx statement missing (
xxx语句缺少左括号
xxx statement missing )
xxx语句缺少右括号
xxx statement missing ;
xxx缺少分号
xxx`` declared but never used
说明了xxx但没有使用
xxx`` is assigned a value which is never used
给xxx赋了值但未用过
Zero length structure
结构体的长度为零

eCos最大的特点是内核可配置。它出生于1997年，相对其他的系统来说是非常年轻的，但是也正是因为出身的晚，所以在设计理念上面是比较新颖的。其全部代码使用C++编写。
eCos可以说是嵌入式领域的一颗新星，全称是Embedded Configurable Operating System。绝大多数代码使用C++写作完成。最早是Cygnus公司开发（是不是想到Cygwin了？），不久被RedHat收购，现在RedHat 又放弃了RedHat项目，解雇了eCos的开发人员，将他踢到了Free Found Org(这是我坚决不用RedHat的原因，太功利了)。
eCos最大的特点是模块化，内核可配置。如果说嵌入式Linux太庞大了，那么eCos可能就能够满足要求。它是一个针对16位、32位和64位处理器的可移植开放源代码的嵌入式RTOS。和嵌入式Linux不同，它是由专门设计嵌入式系统的工作组设计的。ECOS具有相当丰富的特性和一个配置工具，后者能够让你选取你所需要的特性。Linux兼容的嵌入式系统在内核裁减后编译出来的二进制代码大小在500k字节以上，这还只包含最简单的内核模块，几乎没有加载任何其他的驱动与协议栈。
但是eCos最小版本只有几百个字节，一般，一个完整的网路应用，其二进制的代码也就100K字节左右。而且更为重要的是，eCos提供的Linux兼容的API能让开发人员轻松的将linux应用移植（这点和RTEMS很相似），与此同时，应用程序不用跑在Linux复杂的内核机制上（这套机制，对于大型服务器也许还凑合，但是对于短小精干的嵌入式应用，太浪费了），大大节省了你的晶振和RAM。
eCos 中字面上C（configurable） 表示的“高可配置性”。eCos 可以让开发者像在玩积木般地自由选择其执行期的元件，应用程序开发者可以针对自己的应用程序来设迟一个对其最小的RTOS环境，这跟以往应用程序就是跑在一个完整的RTOS上本质上不同，在嵌入式系统資源与内存寸土寸金的环境上，这样的开发方式是很重要的。在以往的嵌入式开发方式都是自己手工的将RTOS 作缩减，对经验不足或对该RTOS不夠熟悉的人将会花去许多时间，或是根本很难将RTOS拆开，但在eCos 上，由于设计之初就是朝向可设迟的原則，各种元件都遵守著模块化的开发方式，而应用程序开发者只要使用eCos 中的配置，即可轻松简单的对eCos 元件作量身打造，也不需对其內部实作有所了解即时RTOS的核心并提供标准系统API。
eCos 的核心支持一般OS 常見的项目如驱动程序（Device Driver）、内存管理（Memory managemant）、异常处理（exception handling）、中断处理（exception handling）、线程的支持（thread support）、计时器（Timer）、计数器（Counter），对于即时RTOS的支持如完全优先（full preemptability）、最小中断延迟（minimal interrupt latencies ）、线程同步（synchronization primitive）、可自定的调度原则（schedule policies）。
此外也支持POSIX 等操作系统的标准API 及ANSI C 与常用的数学函数。支持常用的周边及通讯协议( networking stacks)支持以太网络卡，串口，USB slave等常用周边。并支持一般常用的通讯协议如IP、IPV6、ICMP、UDP、TCP、SNMP、HTTP、TFTP、FTP 等。网络设迟部分，可支持静态IP 与DHCP 。GDB支持可支持主控端使用GDB 远端透过串口或是以太网络对应用程序除错。
此外， eCos另一个优点是他支持非常多的平台和CPU，尤其是比较新的CPU比如ARM的各个系列，DSP（BlackFin）等。并且也支持很多硬件平台。目前支持的CPU包括： ARM, CalmRISC, FR-V, H8, IA32, M68K, Matsu****a AM3x, MIPS, NEC V8xx, PowerPC, SPARC, SuperH支持的硬件平台设备包括： Flash, Ethernet, 串口, USB, 时钟等。其已直接支持了时下绝大部分的硬件，可在eCos 官方网站上找到支持列表。具体的硬件支持情况可以参考http://ecos.sourceware.org/hardware.html，里面有长长的一个列表，大家可以根据自己的情况去看看。需要说明的是，这个硬件列表可能很久没有更新过了，最新的硬件列表可能需要访问开发者的邮件列表。
ECos的Licence:
eCos的专利受eCos license 所保护，这是一个GPL license 的修改版，其准许开发者在其上开发的应用程序（eCos 以外自行撰写的部分）可以不用跟著GPL 一起发布。应用程序开发者可免費的取得其完整的源码（buyout-free），并针对其作任意的修改与在其上开发自己的应用程序并发布，唯一的限制只是若有修改到eCos 本身，其需将修改的源码回报給eCos 开发小組。当开发者将其当为产品时，也不需支付版税（royalty-free）。可以看出，eCos的Licence比GPL要宽松。
eCos 上开发的应用程序架构图中File system 指的是对文件系统如ext2 等的支持，library 是上节所提包括POSIX，ANSI C 等的函数库。这张图，由上到下，表示从高层到底层的eCos架构。最底层的是我们的硬件，在硬件上面有HAL 与裝置驱动程序，而我们大部分会利用eCos 工具去设中间kernel、networking stack、library 层（OS层），只留下我们需要的部分。最上层的应用程序就是我们自行撰写的部分，通过中间OS 层的辅助来达成我们的目的。
我们可以看出，Redboot 是一个架构在eCos HAL 与Device Driver 上的一套应用程序。其中与硬件最关系密切的就是HAL，可以用“最接近硬件的软件”来形容，HAL 将所有与硬件相关的地方对外隱藏在里面。针对不同的硬件时，只需换掉HAL，换上针对新硬件而撰写的HAL 即可。

摘要 uClinux和eCos操作系统是两种性能优良、源码公开且被广泛应用的免费嵌入式操作系统。本文通过对uclinux和eCos的对比，分析和总结了嵌入式操作系统应用中的若干重要问题，归纳出嵌入式系统开发中操作系统的选型依据。
关键词 嵌入式 操作系统 eC0s uClinux

1 两种开源嵌入式操作系统介绍
uClinux是一种优秀的嵌入式Linux版本。 uClinux是micro-Conrol-linux的缩写。与标准Linux相比，它集成了标准Linux操作系统的稳定性、强大网络功能和出色的文件系统等主要优点。但是由于没有MMU(内存管理单元)，故其多任务的实现需要一定技巧。
    eCos(embedded Configurable operating system)，即嵌入式可配置操作系统，是RedHat的产品，但eCos并不是Linux或Linux的派生。eCos弥补了Linux在嵌入式应用领域的不足，是一个源码开放的可配置、可移植、无版税、面向深嵌入式应用的实时操作系统。eCos的核心部分是由不同的组件组成的，包括内核、C语言库和底层运行包等。每个组件能提供大量的可配置选项，利用eCos提供的配置工具可以很方便地进行配置。通过不同的配置使得eCos能够满足不同的嵌入式应用。
    对于以上两种源码公开的实时操作系统，主要从以下几个方面进行比较。通过比较，能够为大家选择适合自己系统的RTOS提供参考。

2 基本操作性能的比较
2.1 应用程序的运算能力
在Linux 和uClinux操作系统启动的时候，都会有这样一句话——Calibrating delay 1oop．．0k—xxx BogoMips，这一过程叫作BogoMips(读作bogumips)。Linus Torvalds引入BogoMips主要有两个目的：①给用户一个大概的系统运算能力的概念；②由于系统中有许多代码需要精确的软件延时，通过 BogoMips来获得软件延时每个周期消耗的时间。BogoMips的过程就是一个简单计数循环，看ls可以循环多少次，然后除以500000就得到了 BogoMips的数值。
    表1是分别在目标硬件平台上运行eCos和uClinux下的BogoMips应用程序得到的结果。我们使用了不同的测试条件，激活和非激活AT76C120的存储器缓冲控制器。

    从表1可知，打开缓冲存储器。对eCos的应用程序性能影响较uClinux的大；反之，关闭缓冲，eCos的应用程序的性能就下降很多。

2．2 存储器访问能力
采用一种同时能够测试缓冲控制器和标准存储器访问函数的测试方法来测试存储器访问能力。在这里，选用田纳西大学的Philip J．Mucci等人提出的CacheBench方法。其工作原理是，重复顺序读／写一定长度的存储器块的数据，记录重复n次所用的时问，用总的读／写数据除以耗时，得到读／写每一字节所用的时间；同时，通过调整数据块的长度和不同的读写方法(使用标准函数或者使用直接代码读写)，获得不同条件对存储器读／写的影响。
    在实验中，对于每一种测试模式使用4种不同的块长度(分别为256、512、1024、2048字节)，以观察不同的抉长度对存储器访问性能的影响。表2 是实验的结果：横向比较，eCos的存储器访问性能从总体上都优于uClinux；纵向比较，5种模式下性能关系大致为缓冲读>缓冲读，改写／写 >缓冲写>mcmset>mcmcpy。在同一种测试模式下，对于缓冲读，越大的块长度，其表现的存储器访问性能越好；而其他模式下，存储器访问性能基本与块长度无关。

    基于以上结果的分析如下：①造成eCos存储器访问能力优于uClinux的原因是，eCos的应用程序获得的处理器时间较长；②造成读缓冲模式下，存储器访问性能随块长度增长而变好，而其他模式下不变的原因是，与AT76C120的缓冲控制器的回写模式有关。由于AT76C120的缓冲控制器采用了直接回写的缓冲回写模式，缓冲控制器对存储器写操作没有任何缓冲作用，因此当处理器写存储器时基本不会享受到由缓冲控制器带来的好处，相当于直接访问外部存储器。

2．3 驱动程序性能测试
为了测试系统的驱动程序性能，选择CF卡驱动程序作为测试对象。我们的测试方法简单，就是在应用程序中打开一个大文件(10MB)，然后调用fread读文件，每次读512字节到缓冲中，直至将文件读完。
    表3是测试结果：uClinux的性能优于eCos。这主要是由于uClinux的块驱动有一个叫集簇的功能，它可以将对块设备的多个请求归并在一起执行，这样对于像磁盘这样反应较慢的设备可以提高整体的读／写速度。

3 综合应用性能比较
    我们知道，一个图像压缩和解压缩的程序往往需要大块的存储器访问操作、密集的数学运算和大量的磁盘访问。由于现在手持的嵌入式设备大多需要有这方面的应用需求，因此一个图像压缩和解压缩的应用程序既符合理论研究的要求，又符合实际应用的需求。为此我们选择gif图片的编解码的程序作为综合性能测试的测试程序。测试结果如表4所列。

    我们看到，eCos和uClinux解码速度都很低，主要是因为完全使用了软件解压缩；而且由于AT76C120的图像显示格式是YCrCb的，而 giflib的解压缩结果是RGB的，因此必须使用浮点运算将RGB的数据转换到YCrCb。AT76C120的ARM7TDMI不支持浮点指令，因此不得不使用软件仿真来完成浮点运算，这其中大部分时间被用在了从RGB到YCrCb的转换上。测试结果基本与前面基本操作系统测试的结果是一致的—— eCos在整体上是优于uClinux的。

4 可移植性
eCos的系统一J移植性应该明显比uClinux的好。在eCos系统中，每一个硬件平台都用一个单独的目录存放针对这一硬件平台的硬件抽象层的代码和配置信息，较容易让用户理解。而uClinux的硬件抽象层的代码分布在好几个目录中，而且各个平台的代码混合在一个源文件中，通过#ifdef+#end的方式来选择不同的硬件平台的代码。另外，eCos在移植时所要更改的源代码文件数少于uClinux。
    可移植性不应仅仅是操作系统的移植，还应该包含应用程序的移植性。程序的可移植性，是由两方面决定的。首先，应用程序必须被编写得可以移植。关于这方面， A．Dolenc，A．Lemmke和D.Keppel在其Notes On WritingPortable Programs In C一文中给出了很好的解释。其次是嵌入式操作系统提供较丰富的系统函数和标准函数库。一个系统提供的函数库越丰富，则越多的应用程序不用进行较大的更改就能直接在其上运行。在标准函数方面，eCos只提供了较为简单的C标准函数库和IEEE浮点运算数学库，uClinux则提供了，与Linux下的 glibc相兼容的函数库，而glibc是大部分开放源代码项目的构建基础。由此可以看出，在应用程序的可移植性上，uClinux的兼容性更好。

5 开发模式和开发难易度
eCos的开发模式是一套更接近传统单片机的开发模式(如应用程序静态链接)，uClinux的开发模式则更接近Linux的开发模式。因此可以预见，eCos更受一批从8位单片机系统开发转到32位嵌入式系统开发设计人员的欢迎．而uClinux更受熟悉Linux的设计人员的青睐。

6 总 结
通过以上比较可知，由于eCos从一开始设汁时就是以嵌入式系统为目标的，因此在性能上，有较大优势；反之，uClinux则是由Linux进化而来的，因此在以速度和优化为主题的嵌入式系统环境中，并不占优势。但是由于有Linux的强大后盾，其功能的强大和兼容性是非常突出的。如果应用程序是从其他系统中移植过来的，或者开发人员有Linux的背景，或者开发成本占总成本的比例较高，则uClinux比较适合；反之，eCos比较适合。

——信息来源：杭州启扬智能科技有限公司

最新的STATSVN可以从其官网上下载： http://www.statsvn.org

StatSVN能够从Subversion版本库中取得信息，然后生成描述项目开发的各种表格和图表。

比如：

代码行数的时间线；

针对每个开发者的代码行数；

开发者的活跃程度；

开发者最近所提交的；

文件数量；

平均文件大小；

最大文件；

哪个文件是修改最多次数的；

目录大小；

带有文件数量和代码行数的Repository tree。

StatSVN当前版本能够生成一组包括表格与图表的静态HTML文档。

StatSVN使用JFreeChart来生成chart。

简易使用流程是：
1:checkout 一份干净的工程
svn checkout –username yourname –password yourpasswd “svn://size/repos/src” c:/checkout

2:生成log
svn log –username yourname –password yourpasswd -v –xml c:/checkout > c:/checkout/src.log

3:生成统计结果
java -jar statsvn.jar -title yourtitle -username yourname  -password yourpasswd  -output-dir c:/report -include **/*.java;**/*.jsp;**/*.js;**/*.css;**/*.c;**/*.cpp;**/*.cs;**/*.vm;**/*.h;**/*.hpp;**/*.asp;**/*.xml;**/*.pas;**/*.dfm;**/*.php;**/*.pl;**/*.py -exclude **/*.gif;**/*.jpg;**/*.png;**/*.bmp;**/*.zip;**/*.rar -threads 50 c:/checkout/src.log c:/checkout

注意：

由于SVN的diff的计算算法问题，如果第一次执行statsvn可能会耗费很长时间的，我自己的一个20w行左右的项目，第一运行就花掉了1个多小时，所以请耐心等待，以后再执行就很快了。

附上几张统计结果的图片：

转载自：http://blog.csdn.net/absurd

去年花了一个多月时间，为arm-linux平台编译程序库，其中包括zlib、readline、ncurses、tslib、TinyX、libpng、jpeg、cairo、pango、glib、atk、gtk+、match系列、SCIM、GPE系列。由于之前没有经验，走了不少弯路，虽然从中学到了一些知识，大部分时间都浪费了。最近一些同事和朋友常问我一些关于交叉编译的问题，我想有必要总结一下，和大家分享一些心得。

什么是交叉编译呢？在回答这个问题前，我们先解释两个概念：

主 机：运行编译过程的计算机。

目标机：运行编译结果(可执行文件)的计算机。

一般情况下，主机和目标机是同一类型的计算机，这就是正常的编译，没有什么好说的。所谓交叉编译就是在主机上为目标机编译，比如在PC上编译，然后在手机上运行，这种编译就叫交叉编译。

交叉编译需要交叉编译器，不同的目标机(主要是看芯片类型)需要不同的交叉编译器，比如我们这里要介绍的arm-linux交叉编译，所用的交叉编译器就是arm-linux-gcc系列。

构建一个交叉编译器(toolchain)，说简单也简单，说复杂也复杂。原理上很简单，实际情况常常比较复杂，原因是编译器一直处于开发状态，你要了解某个版本的稳定性，要去找patch。有时候还要看你的运气好不好，折腾一个星期才搞定也是很常见的。

网上已经有不少已经构建好了的交叉编译器(toolchain)，除非你想了解如何构建交叉编译器，否则直接下载一个来用是比较明智的做法。这里不打算介绍如何构建交叉编译器的知识。

在做交叉编译前，你最好了解autoconf系统工具的用法，遇到问题时，可以快速定位。先找一本autoconf的书看看，可以说是磨刀不识砍柴功，否则后面会浪费更多的时间。

你是第个访问者