Linux 2.6内核的精彩世界 点击:1127 | 回复:3



gongkongedit

    
  • 精华:1099帖
  • 求助:0帖
  • 帖子:14392帖 | 54470回
  • 年度积分:0
  • 历史总积分:622
  • 注册:2008年9月08日
发表于:2004-02-20 11:54:00
楼主
Linux 2.6 扩展多平台支持的一个主要途径就是把uClinux的大部并入了主流内核(mainstream kernel)。uCLinux(可以发音为"you-see-Linux",但更正确的拼写,首字母应该式希腊字母"mu")是将Linux应用在微控制器平台的项目。很多年来,这个Linux分支为许多嵌入式芯片提供了支持,把它更多的集成到主流内核中是一件非常有意义的事。 不像通常的Linux移植版本,这里描述的嵌入式移植版由于硬件限制和通常的Linux相比,不具有所有类似的特性。主要的区别在于:这些移植版是针对于没有内存管理单元(MMU)的处理器的(Intel的CPU从386开始就有MMU了)。缺少MMU的支持,运行真正的多任务系统时,任务之间没有内存保护机制(因此任何程序都可以使得其他程序崩溃),一些有关进程派生的系统调用也无法实现。正是因为没有内存保护机制(或者说,没有任何安全性可言),它们不适用于多用户系统。 在对嵌入式处理器支持上,Linux 2.6有四个主要的新进步。首先是对Motorola的新型嵌入式m68k系列处理器移植。这些被命名为Dragonball或是ColdFire的处理器可以在Motorola,Lineo,Arcturus或是其他厂商生产的系统或是评估板上找到。大多数Linux用户应该对这些处理器相当熟悉,因为从Palm 1000到最新的Palm III,他们一直是Palm Pilots的心脏。不幸的是,对早期没有MMU的m68k处理器(比如早期苹果机上使用的68000系列)还没有支持。最新支持的嵌入式平台还包括日立(Hitachi)的H8/300系列(不包含H8S,但可能会尽快地集成进来)以及NEC v850处理器。 无论怎么强调Linux 2.6旨在支持无MMU系统的主要体系结构变化,都不为过分。所有Linux的前期版本,不论直接或是间接,都起源于Linus最初在Intel 80386上的工作,局限性是固有的。沿着这个方向(对无MMU系统的支持),将来也许会有更多的其他早期的硬件被支持(事实上,已经有关于此目的的项目启动)。但是,不像为现代的以及仍在生产中的嵌入式处理器的提供支持,对早期的硬件的支持被更多地认为是基于某种爱好,并且对于最终用户而言很可能是无用的(因此在今后的Linux的官方发布版本也许不会将其包含在内)。 最新的Linux版本包含了对Axis通信公司的ETAX CRIS("Code Reduced Instruction Set")处理器的支持(更确切地说,支持ETRAX 100LX及更新的产品),它从技术的角度而言不是uCLinux合并的一部分(因为它包含MMU单元)。实际上对这款处理器的支持在2.4开发周期就已经有了,但它在2.4.0以后才被引入,所以现在应该提到它。它是主要用于网络设备的嵌入式处理器。与此相关的ETRAX 100,是得到uClinux支持的无MMU处理器,但是在主流的Linux内核中相关支持却没有集成进来。 Opteron支持 - 消费级的64位Linux 另一个在2.4.x开发环节就已经并入但这里仍然值得提及的是对AMD Opteron芯片(基于AMD64体系结构)的支持。Opteron向后与Intel-clone的处理器兼容,并且,甚至可能得到微软的支持。是它还是Intel的Itanium家族的某一成员成为64位消费级产品的事实标准现在还很难下定论。 尽管2.4系列内核的后期版本已经可以在该芯片上运行,但作为产品应用仍受到了很大限制。对高端用户来说,最严重的问题是,每个应用程序的RAM的使用都被限制在512MB以内。另一方面,新内核对在该平台上运行x86(32位)的程序的支持得到了改进。 子体系结构(Subarchitecture)支持 Linux 2.6除了对许多新的处理器体系结构外,还包含了一个称为子体系结构(Subarchitecture)的新概念。以前,Linux通常假设处理器和其他硬件是配套的。也就是说,i386系列处理器只会在PC/AT服务器上使用。这条针对i386的假设在Linux 2.4中就被打破,因为i386的额外支持使其可以在SGI的视频工作站(Visual Workstation)中使用。(事实上,在其他非i386体系结构上,这个假设早被打破了。比如,m68k很早就支持Amiga,Michintosh等平台。)Linux 2.6对于此最大的变化就是,让这个特性以及概念成为标准,以便所有的体系结构都可以用相似而健全的方法来处理,以便更清晰地划分模块。 标准的确立使得i386可以运用于两个新的平台。第一个是NCR的Voyager体系。这是一个对称多处理器(SMP)系统(在Intel的MP规范标准确定之前就已经开发出来了),它支持多达32个486-686的处理器配置。实际采取这种体系结构的产品处理器的配置数目要相对少一些,而且目前并不是所有的型号都得到了Linux的支持(最早的就不支持)。第二种得到最新支持的体系结构是更为广泛使用的由NEC开发的PC-9800平台,它曾是日本市场占统治地位的PC平台,一直到最近几年。最初的PC-9800装载的是8086处理器,最终发展到奔腾级处理器和SMP支持。(当然,Linux对它的支持局限在386以上。)尽管在美国它完全不为人所知,微软的Windows 95之前的版本曾移植到这个平台上。该平台由于生产商对标准PC的偏爱,生产已经中止。 Linux对差异细微的硬件类型支持的形式化,使得操作系统能更容易的移植到其他平台上,比如移植到专为存储设计的硬件或者是使用在工业领域的主流处理器。需要澄清的是,子体系结构也不是任何时候都管用的,它能够发挥作用是因为这些可移植的系统非常底层构件(比如IRQ路由)有或多或少的不同。比起在X-box上运行Linux的差别来说,驱动程序等



红星

  • 精华:0帖
  • 求助:0帖
  • 帖子:1帖 | 4回
  • 年度积分:0
  • 历史总积分:57
  • 注册:2004年2月19日
发表于:2004-02-19 13:20:00
1楼
请深入讲一下内存管理单元(MMU)好吗?

gongkongedit

  • 精华:1099帖
  • 求助:0帖
  • 帖子:14392帖 | 54470回
  • 年度积分:0
  • 历史总积分:622
  • 注册:2008年9月08日
发表于:2004-02-19 13:37:00
2楼
内存管理      uCLinux设计针对没有MMU的处理器,即uCLinux不能使用处理器的虚拟内存管理技术。uCLinux仍然采用存储器的分页管理,系统在启动时把实际存储器进行分页。在加载应用程序时程序分页加载。但是由于没有MMU管理,所以实际上uCLinux采用实存储器管理策略。这一点影响了系统工作的很多方面。uCLinux系统对于内存的访问是直接的,所有程序中访问的地址都是实际的物理地址。操作系统对内存空间没有保护,各个进程实际上共享一个运行空间。一个进程在执行前,系统必须为进程分配足够的连续地址空间,然后全部载入主存储器的连续空间中。 uClinux没有MMU管理存储器,在实现多个进程时(fork调用生成子进程)需要实现数据保护。由于uClinux的多进程管理是通过vfork来实现,因此fork等于vfork。这意味着uClinux系统fork调用完成后,要么子进程代替父进程执行(此时父进程已经sleep)直到子进程调用exit退出;要么调用exec执行一个新的进程,这个时候将产生可执行文件的加载,即使这个进程只是父进程的拷贝,这个过程也不能避免。当子进程执行exit或exec后,子进程使用wakeup把父进程唤醒,使父进程继续往下执行。 uClinux的这种多进程实现机制同它的内存管理紧密相关。uClinux针对没有mmu处理器开发,所以被迫使用一种flat方式的内存管理模式,启动新的应用程序时系统必须为应用程序分配存储空间,并立即把应用程序加载到内存。缺少了MMU的内存重映射机制,uClinux必须在可执行文件加载阶段对可执行文件reloc处理,使得程序执行时能够直接使用物理内存。

无幻

  • 精华:0帖
  • 求助:0帖
  • 帖子:0帖 | 4回
  • 年度积分:0
  • 历史总积分:54
  • 注册:2004年2月20日
发表于:2004-02-20 11:54:00
3楼
好像基于2.6内核的系统还没出来吧,而且基于2.4的内核的系统升级到2.6很麻烦的,要等到新的系统出来那就要比较久了,这个内核改了很多,应该称为3.0版本

热门招聘
相关主题

官方公众号

智造工程师