eCos历史(转） 博客分类： eCos 嵌入式RedHat配置管理多线程C
程序员文章站
2024-03-02 10:42:40
...
作者：yansm
时间：2002.12.7
近来学习eCos，会陆续写一些学习总结。今天先聊一下他的可配置机制。
eCos是Cygnus（现为redhat嵌入部门）的嵌入式可配置操作系统，很小，而且支持多种平台。在消费电子等深嵌入应用领域还是很有前途的。
主要参考文献：eCos联机文档
1.什么是可配置
以前的嵌入式系统开发是开发人员改变调整应用来适应底下的操作系统，现在的情况是eCos提供了大范围的可选项供开发人员配置操作系统，以最好地匹配应用 的需求，这样就变成了调整操作系统来适应应用。典型的配置选项包括调度器的类型和任务优先级别数目等。当前,eCos具有200多个配置选项。
因为嵌入式应用中代码和数据的体积是必须考虑的因素，因此可配置能力必须保证不会带来任何这方面的开销。一些配置能力可以通过连结来实现，但为了最大化的 利益，大多数配置在编译阶段进行。如果合适的话，一个配置项只影响单行代码是可能的。另一方面，单个配置项或许会决定着整个tcp/ip栈的取舍。对于用 C或C++写的系统代码来说，采用的主要机制就是C预处理表达式#ifdef。
用#ifdef来提供一些可配置选项，这种想法当然不是什么原创性的工作。关键在于，配置项并不是互相独立的，例如：改变一个内核选项可能会影响到C库还 能否提供线程安全的例程。在eCos中关键的创新是配置项被视为带有依赖描述的数据条目(data items)。有一个图形配置工具使用户可以方便地操纵各种选项，理解各种相互作用，并能够检查配置结果的有效性。
这一配置框架还把系统构件化为不同的包(packages)，包括内核，C库和数学库。可以选择要不要整个包，也可以改变这些包里面的配置项。还可以向系 统添加新包，比如添加一个TCP/IP桟。关键是这些新加的包可以指明其对系统其他部分的依赖关系，例如TCP/IP桟可以指明它需要每线程数据支持 (per-thread data support)。我们期望eCos包的数量随着时间不断扩充，现在已有一些开发者打算把他们现有的软件做成eCos包的形式。
eCos配置系统不影响你开发自己的应用程序的方式。没有必要采用任何特定的语言，没有必要在自己的代码中提供大量配置项，也没有必要使用专门的开发环境。配置系统的主要输出是一个要与你的应用代码连接的库。
2.eCos不支持存储管理
eCos是一个单进程多线程的操作环境，因而不需要内存管理功能，在存在内存管理硬件的平台上，为了提高性能，相关功能也许会被用到，比如在基于PowerPC的平台上，内存管理被用于使能cache操作。
eCos不存在独立地址空间的概念。所有线程共享同一地址空间和访问权限。值得指出的是3G Lab做了一些实验性工作，他们为StrongARM SA1110提供保护地址空间。
3.eCos的历史渊源
这本来应该在第一篇讲的，可是当时找不到相关的资料，在这里算是补缺吧。
Cygnus Solutions于1989年成立，创始人为Michael Tiemann,David Henkel-Wallace,和John Gilmore。这个公司的商业模型是提供高质量的开源软件支持和开发。就是说他们主要是为客户做工程技术支持工作，后来的发展证明这种商业模式是很成功 的——他们接到了大量的单子（虽然我还是在校学生已经感受到it业冬天的寒冷，那么，今天我们能否借鉴一下这种商业模式呢？即以我们的专业的优秀技术进行 相关的技术咨询支持工作或者说与帮助客户进行项目的开发，通过这种行为来盈利。有兴趣的兄弟可以与我联系。）。但是，因为项目是各种各样的，他们为了这些 单子所付出的工作是很繁重的。所以，Cyguus不得不把注意力缩小，他们决定通过改进GNU的gcc、gdb并把他们集成在一起销售来盈利。通过努力， 终于有了成果——就是今天的GNUPro开发工具包，也就是eCos的开发工具。
为了向市场提供一个高效的、高质量的嵌入式软件方案，eCos的开发于1997年被提到了日程上。eCos将和GNUPro相辅相成，扩大Cygnus的 产品线。eCos一开始就考虑到了嵌入式系统中内存资源的限制以及嵌入式硬件平台的多样性。它提供了硬件平台的抽象机制，并且具有高度的可配置能力，这使 得它能适用于各种硬件以及不同级别的硬件配置。eCos强大的配置工具可以显著缩短产品开发周期。另外关键一点在于它是开放源码的（开发工具和操作系 统），这样可以降低系统成本——这是嵌入式系统中一个非常重要的因素。用户可以*使用eCos，但是对eCos的改动应该公布出来，这是为了提高或促进 eCos发展的一种措施。当然，用户的应用程序不必公开。
后来，Cygnus Solution被RedHat收购，作为RedHat嵌入式部门继续eCos的开发。现在最新版本是2.0。不过，Cygnus Solution原来的员工2002年有些人被RedHat解雇了，在一定程度上影响了人们对eCos的信心。不过，RedHat随即宣称将继续支持 eCos的发展，相信凭借RedHat的技术后盾以及广大eCos用户的积极参与，eCos肯定会得到更大的发展，并获得越来越广泛的注意。
4.eCos的核心组件
实时嵌入操作系统包含一些标准的功能，例如中断和异常处理，线程同步机制，调度器和驱动程序等，这些也构成了eCos的核心组件。具体包括：
硬件抽象层(HAL)：用来来向上层提供统一的硬件视图，屏蔽硬件的差异
内核： 包括异常处理，线程同步支持，调度器，定时器，计数器
ISO C和数学库：标准C函数库
设备驱动程序：标准串口，以太网卡，Flash ROM等
GDB支持：使得目标机上可以和主机通讯进行交叉调试
5. 支持的平台
eCos支持很多种平台，包括ARM,Hitachi,SuperH,NEC,PPC,MIPS,SPARC等等。具体列表见http: //sources.redhat.com/ecos/hardware.html。针对新的体系结构，只需要移植eCos的HAL层，上层应用基本上可 以不必或稍加改动。
6.LICENSE：RHEPL和GPL
1.3.1版本遵循RHEPL，2.0遵循GPL。其实他们基本上是遵循GPL开放源码的。这意味着要求你把你对eCos操作系统代码的改动开放给别人， 但你的应用程序不必开放。但是，GPL这个LICENSE你要是真的违反了，他们也拿你没辙。现在很多LINUX上的东西就是这样。详细信息见 http://sources.redhat.com/fom-serv/ecos/cache/4.html
时间：2002.12.7
近来学习eCos，会陆续写一些学习总结。今天先聊一下他的可配置机制。
eCos是Cygnus（现为redhat嵌入部门）的嵌入式可配置操作系统，很小，而且支持多种平台。在消费电子等深嵌入应用领域还是很有前途的。
主要参考文献：eCos联机文档
1.什么是可配置
以前的嵌入式系统开发是开发人员改变调整应用来适应底下的操作系统，现在的情况是eCos提供了大范围的可选项供开发人员配置操作系统，以最好地匹配应用 的需求，这样就变成了调整操作系统来适应应用。典型的配置选项包括调度器的类型和任务优先级别数目等。当前,eCos具有200多个配置选项。
因为嵌入式应用中代码和数据的体积是必须考虑的因素，因此可配置能力必须保证不会带来任何这方面的开销。一些配置能力可以通过连结来实现，但为了最大化的 利益，大多数配置在编译阶段进行。如果合适的话，一个配置项只影响单行代码是可能的。另一方面，单个配置项或许会决定着整个tcp/ip栈的取舍。对于用 C或C++写的系统代码来说，采用的主要机制就是C预处理表达式#ifdef。
用#ifdef来提供一些可配置选项，这种想法当然不是什么原创性的工作。关键在于，配置项并不是互相独立的，例如：改变一个内核选项可能会影响到C库还 能否提供线程安全的例程。在eCos中关键的创新是配置项被视为带有依赖描述的数据条目(data items)。有一个图形配置工具使用户可以方便地操纵各种选项，理解各种相互作用，并能够检查配置结果的有效性。
这一配置框架还把系统构件化为不同的包(packages)，包括内核，C库和数学库。可以选择要不要整个包，也可以改变这些包里面的配置项。还可以向系 统添加新包，比如添加一个TCP/IP桟。关键是这些新加的包可以指明其对系统其他部分的依赖关系，例如TCP/IP桟可以指明它需要每线程数据支持 (per-thread data support)。我们期望eCos包的数量随着时间不断扩充，现在已有一些开发者打算把他们现有的软件做成eCos包的形式。
eCos配置系统不影响你开发自己的应用程序的方式。没有必要采用任何特定的语言，没有必要在自己的代码中提供大量配置项，也没有必要使用专门的开发环境。配置系统的主要输出是一个要与你的应用代码连接的库。
2.eCos不支持存储管理
eCos是一个单进程多线程的操作环境，因而不需要内存管理功能，在存在内存管理硬件的平台上，为了提高性能，相关功能也许会被用到，比如在基于PowerPC的平台上，内存管理被用于使能cache操作。
eCos不存在独立地址空间的概念。所有线程共享同一地址空间和访问权限。值得指出的是3G Lab做了一些实验性工作，他们为StrongARM SA1110提供保护地址空间。
3.eCos的历史渊源
这本来应该在第一篇讲的，可是当时找不到相关的资料，在这里算是补缺吧。
Cygnus Solutions于1989年成立，创始人为Michael Tiemann,David Henkel-Wallace,和John Gilmore。这个公司的商业模型是提供高质量的开源软件支持和开发。就是说他们主要是为客户做工程技术支持工作，后来的发展证明这种商业模式是很成功 的——他们接到了大量的单子（虽然我还是在校学生已经感受到it业冬天的寒冷，那么，今天我们能否借鉴一下这种商业模式呢？即以我们的专业的优秀技术进行 相关的技术咨询支持工作或者说与帮助客户进行项目的开发，通过这种行为来盈利。有兴趣的兄弟可以与我联系。）。但是，因为项目是各种各样的，他们为了这些 单子所付出的工作是很繁重的。所以，Cyguus不得不把注意力缩小，他们决定通过改进GNU的gcc、gdb并把他们集成在一起销售来盈利。通过努力， 终于有了成果——就是今天的GNUPro开发工具包，也就是eCos的开发工具。
为了向市场提供一个高效的、高质量的嵌入式软件方案，eCos的开发于1997年被提到了日程上。eCos将和GNUPro相辅相成，扩大Cygnus的 产品线。eCos一开始就考虑到了嵌入式系统中内存资源的限制以及嵌入式硬件平台的多样性。它提供了硬件平台的抽象机制，并且具有高度的可配置能力，这使 得它能适用于各种硬件以及不同级别的硬件配置。eCos强大的配置工具可以显著缩短产品开发周期。另外关键一点在于它是开放源码的（开发工具和操作系 统），这样可以降低系统成本——这是嵌入式系统中一个非常重要的因素。用户可以*使用eCos，但是对eCos的改动应该公布出来，这是为了提高或促进 eCos发展的一种措施。当然，用户的应用程序不必公开。
后来，Cygnus Solution被RedHat收购，作为RedHat嵌入式部门继续eCos的开发。现在最新版本是2.0。不过，Cygnus Solution原来的员工2002年有些人被RedHat解雇了，在一定程度上影响了人们对eCos的信心。不过，RedHat随即宣称将继续支持 eCos的发展，相信凭借RedHat的技术后盾以及广大eCos用户的积极参与，eCos肯定会得到更大的发展，并获得越来越广泛的注意。
4.eCos的核心组件
实时嵌入操作系统包含一些标准的功能，例如中断和异常处理，线程同步机制，调度器和驱动程序等，这些也构成了eCos的核心组件。具体包括：
硬件抽象层(HAL)：用来来向上层提供统一的硬件视图，屏蔽硬件的差异
内核： 包括异常处理，线程同步支持，调度器，定时器，计数器
ISO C和数学库：标准C函数库
设备驱动程序：标准串口，以太网卡，Flash ROM等
GDB支持：使得目标机上可以和主机通讯进行交叉调试
5. 支持的平台
eCos支持很多种平台，包括ARM,Hitachi,SuperH,NEC,PPC,MIPS,SPARC等等。具体列表见http: //sources.redhat.com/ecos/hardware.html。针对新的体系结构，只需要移植eCos的HAL层，上层应用基本上可 以不必或稍加改动。
6.LICENSE：RHEPL和GPL
1.3.1版本遵循RHEPL，2.0遵循GPL。其实他们基本上是遵循GPL开放源码的。这意味着要求你把你对eCos操作系统代码的改动开放给别人， 但你的应用程序不必开放。但是，GPL这个LICENSE你要是真的违反了，他们也拿你没辙。现在很多LINUX上的东西就是这样。详细信息见 http://sources.redhat.com/fom-serv/ecos/cache/4.html