关于Linux迎接挑战的序列对话

陆首群教授与吴峰光博士

关于Linux迎接挑战的序列对话

中国开源软件推进联盟专家委员会

The Sequence Dialogue to Meet the Challenge in Regard to Linux

Linux创始人Linus Torvalds说：Android就是Linux操作系统，今天全球持有Android智能手机的人已超过20亿；全球500台运行速度最快的超级计算机80％采用Linux；在网络领域，由中国企业（中移动.华为）主导的基于Linux的主流开源项目Open-O最近创新成功，该项目涉及网络管理和编排领域的创新，它将重新定义SDN的基础架构，指导全球一些大规模通信网络的部署和管理；甚至连微软的云计算平台今年8月也引入红帽的Linux（企业版）操作系统。Linux无处不在，但遭遇挑战。今发表中国开源软件推进联盟名誉主席陆首群教授和Linux基金会Linux大规模自动化测试专家吴峰光博士对话：“关于Linux迎接挑战的序列对话（之一、之二、之三）。

（陆首群教授，中国开源软件推进联盟名誉主席，以下简称“陆”；吴峰光博士，Linux基金会Linux大规模自动化测试专家，以下简称“吴”）

第一篇

陆：今天要跟你讨论的问题主要是Linux在发展中遇到了哪些挑战，我准备给Linux基金会创始人Linus Torvalds写信，问他有哪些应对措施。在写信前先跟你讨论：

第一个问题：有人说Linux的发展似乎不是从用户的需求出发的，而是来自开发者的创意。如果长此下去，是否会使Linux发展迷失方向？

第二个问题：Linux开发支持基于X86的主流架构，Linux虽然也支持多架构如arm、mips…等，但其他架构是非主流的，支持力度恐怕要弱，面对PC向移动继而又向IoT发展形势，长期以X86作为支持的主流架构是否会阻碍Linux的发展？

第三个问题：最近谷歌开发了用于物联网（IoT）领域新的操作系统开源的Fuchsia，其特点是小型化和实时性，而作为通用操作系统的Linux（大量用于移动终端也可用于桌面系统）相对来说功能多，结构复杂、体积臃肿，难以做到小型化实时性，但IoT是当前和未来影响极大的大市场，Linux（用于IoT）是否要迎接挑战呢？

吴：陆主席，您好！

关于您电话中提到的三个问题，我的感觉是第一个问题是虚的，第三个问题是实实在在的，第二个问题很大程度上根源于arm厂商和市场的特质。

1、开发者与用户需求问题

Linux开发者以用户需求为依据，大体上可以分为两类：

●-Linux代码贡献者：主要是各个下游厂商的开发者，或者团体/个人用户，他们是需求的提出者和实现者，是主要推动力量；

●-Linux维护者：站在Linux Kernel长远发展的角度，审查代码，改进架构，确保质量，性能和长期可维护性。维护者对于各个厂商基本持兼容并包的态度，其立场一般是中立的从技术角度看问题。这样的体系基本上是合理的，体现了Linux社区驱动的性质：需求主要来源于社区力量，体现为企业/个人用户的代码提交。

2、X86/arm问题

如1.所述，Linus及其维护者团队努力维持其自主性，鼓励各厂商的开发者以“独立贡献者”（Individual Contributor）的方式贡献代码。

Linus对X86支持的好，源自于两个主要因素：

●-X86是主流硬件，大部分的用户和开发者都在用X86，自然而然它的功能、性能、bug反馈都有先天优势。

陆首群，曾任北京电子振兴办公室主任兼北京市政府电子工业办公室主任；中国长城计算机集团公司董事长，中国吉通通信公司名誉董事长，中国联通通信公司筹建负责人（之一），首都信息发展股份有限公司名誉董事长；曾任国务院信息办常务副主任（主持组织金桥、金卡、金关、金税工程顶层设计，主持筹建中国首批四大互联网），中国工业经济联合会副会长；曾应聘任中国人民银行、航天工业部、广电部信息化高级顾问。

●-X86开发较为有序，ARM相对涣散。特别是在Linario组织出现之前。

ARM阵营里的厂商竞争多于合作，导致ARM这个体系结构的维护状态跟它拥有的开发者数量不相称。很典型的就是ARM里的子架构非常多，高达74个，每个厂商自搞一套，代码互相拷贝粘贴，大同而小异。造成维护的噩梦，Linus对此深恶痛绝，屡屡批评和督促ARM开发者向X86开发者学习。Linaro组织的出现就是朝这个方向的一个重要努力。ARM架构的代码修改量很长时间以来都比X86架构的修改量大得多，代码绝对数量也更大：ARM，380K代码行数；X86，260K代码行数。这说明ARM不缺开发者，可惜各自为战的成分多了些。除此之外，各Android手机厂商开发的数量庞大的代码，大部分都没往上游推。主要是有很强大的产品快速上市的压力。前后产品之间的代码复用都很难。相比而言，服务器厂商在产品开发和生态培育上更有节奏感，能长期稳健投入，建设起一个体系。

Linux从1995年发布1.2.0开始就支持多种硬件架构了。这时候的Linux还处于幼儿阶段，代码简单。这么早就引入多体系架构的支持，意味着Linux从设计上对多架构的支持是完善和具有前瞻性的。如果某些架构表现不好，大概只能从这个体系架构的厂商那里去找原因了。

3、IoT

IoT对于Linux的确是一大挑战。主要是大小和延迟两方面的挑战。一方面是因为Linux的成功发展导致了臃肿和复杂。另一方面是Linux是社区驱动的，来自于嵌入式厂商的驱动力量偏于薄弱。我倡议相关的嵌入式厂商和开发者采取切实的行动，贡献自己力所能及的力量，让Linux在小设备上跑得更好。社区的创造源泉来自于包括你我在内的每个参与者。像一个嵌入式系统。我除了想与你探讨Linux和Fuchsia的关系外，还请你搜集一些具体数据（我本人也搜集中）。我感到有兴趣的是Linux如何应对挑战，首先想听你的意见。

吴：陆主席，您好！

关于Linux/Fuchsia的调研如下，还有若干问题我后面继续补充。Linux在IoT领域面临两个基本挑战：1）内核大小，2）响应延迟。有些设备太小没法跑Linux；有些设备要求低延迟也没法用Linux。对于这些设备，为它们专门设计的各种IoTOS会是恰当的选择。Linux的设计目标是一个通用操作系统，大量技术上的Design Trade Off就会往该目标上倾斜，再加支持上非常多的功能而导致的复杂性，要克服上述两个挑战相当不容易。实际上Linux内核的最小大小随着功能的增多一直在增长，见下图。

来源是http://events.linuxfoundation.org/sites/events/files/slid es/tiny.pdf。Linux与RTOS的延迟比较，见下图，

第二篇

陆：最近Google开发新的操作系统Fuchsia，其内核Magenta（基于Little Kernel，LK），与Android（Linux OS）及Linux（Kernel）有什么差别呢？它的应用范围是IoT、移动终端、桌面系统。我看它主要用于IoT，说要扩展到桌面操作系统领域，似乎有点吹牛。我还是认为，Linux和Fuchsia应用范围是各司其职。它与Linux操作系统最大的区别是它能做到小型化和实时操作，Linux作为一个通用操作系统，代码影像尺寸（内存空间）愈来愈大，响应时间愈来愈长（难以实时操作）。时代在变化，由PC（桌面系统）而移动（终端）继而物联网（IoT），IoT是“第四次工业革命”的主要领域。Linux的发展是否也会与时俱进？Linux有没有瘦身化的目标？你电话中告诉我，Linux也有精简版，恐怕这时尚难做到小型化和实时操作。还有一点，Fuchsia还不至于小到

来源是http://www.embedded.com/electronics-blogs/break-poi nts/4372868/Linux-Wins---Or-Does-It-，

当然Linux也在改进，比如这份技术白皮书：

Linux As a Real-Time Operation System 11/2005

http://www.nxp.com/files/soft_dev_tools/doc/white_pa per/CWLNXRTOSWP.pdf。

对于硬件能力稍强的设备，相应的会对软件能力和生态有更高的要求和依赖。Linux应当发挥积极的作用，把这些设备支持好。但是持续增长的内核大小说明Linux对它们的支持正在恶化。说明在Linux社区中缺少足够的力量来监测和优化内核大小。问题可能在于：手机及嵌入式领域的厂家投入了大量的人力来让Linux在自家的平台上跑的好，但是一般来说缺乏热情，把产品代码整理干净，变成质量高通用性好的代码，并把它推入上游Linux的代码库。桌面及服务器厂商的态度就是（比如Intel、Red Hat）upstream first，先把代码贡献给上游，然后在自家产品中采用或移植（Backport）。两种态度造成的差别就是：Linux对桌面和服务器支持相当好，然而在嵌入式领域的表现不尽如人意。据我所知Linux下游厂商的开发者数量要比上游维护者大两个数量级。他们作为最了解需求，掌握最多开发者的大客户不贡献代码，上游维护者想要迎合用户需求也难。Linus及其维护团队主要职责还是在于质量把关和确保架构合理。大体上Linux Kernel的发展方向是被各类用户推着走的。哪一类（厂商）用户比较给力，Linux在哪方面就发展的好。

第三篇

陆：峰光，请帮忙查一下Fuchsia/Magenta/Little Kernel的内存，以及Android/Linux（Kernel）的内存。我有其它渠道也在查，但我希望获得你的数据和评说。

吴：陆主席，您好！

Fuchsia/Magenta跑起来需要多少内存还不清楚。我需要编译看看。

代码量是知道的：

代码行数（SLOC）人年项目历史

Linux v4.814M47351991 Linux 0.018k1.81991 LittleKernel75k202008 Magenta103k27最近公开，估计内部研发有一两年了

如果把第三方代码也算进去：LittleKernel506k138

Magenta294k78

kernel size ROM sizeRAM size

LittleKernel15-20 KB（映像文件）

Zephyr8-512 KB（映像文件）10 KB（内存需求量）（由Intel/WindRiver捐献给Linux Foundation）

Linux（MCU）1 MB2 MB256 KB（XIP）（XIP，eXecution in Place）

Linux（MicroYocto）800 KB＜8 MB1.6 MB

Linux（wifirouters）3-5 MB2-8 MB8-64 MB Linux迷你桌面系统：

Damn Small Linux 50 MB16 MB Tiny Core Linux 16 MB46 MB NanoLinux14 MB64 MB Lubuntu744 MB512 MB

以上是各类精简版Linux的大小。

吴：LittleKernel编译出来的大小是232K：

232Kbuild-qemu-virt-a15-test/lk.elf

Fuchsia/Magenta编译出来了，整个内核加用户态映像文件大小是3 MB左右：

3.5M/c/fuchsia/magenta/build-magenta-pc-x86-64/magenta. elf

2.7M/c/fuchsia/magenta/build-magenta-qemu-arm32/magenta.elf

这是不带图形功能的。不过跑不起来，死机了：invalid opcode，halting

CS：0x10 RIP：0x4c EFL：0x2 CR2：0

RAX：0x2 RBX：0x3f RCX：0

RDX：0

RSI：0x8 RDI：0xdRBP：0xffffffff80473be8 RSP：0xffffffff804d0fa0 R8：0xffffffff804d0fc0 R9：0xffffffff804cfe04 R10：0xffffffff804cfe0c R11：0xffffffff804cfe08

R12：0 R13：0 R14：0 R15：0 errc：0

bottom of kernel stack at 0xffffffff804d0ef0：

0xffffffff804d0ef0：0000000d 00000000 00000008 00000000|……………|

0xffffffff804d0f00：80473be8 ffffffff 0000003f 00000000|.；G……？……|

0xffffffff804d0f10：00000000 00000000 00000000 00000000|……………|

0xffffffff804d0f20：00000002 00000000 804d0fc0 ffffffff|………M……|

0xffffffff804d0f30：804cfe04 ffffffff 804cfe0c ffffffff|L……L……|

0xffffffff804d0f40：804cfe08 ffffffff 00000000 00000000|L…………|

0xffffffff804d0f50：00000000 00000000 00000000 00000000|……………|

0xffffffff804d0f60：00000000 00000000 00000006 00000000|……………|

QEMU：Terminated

吴：LittleKernel编译出来的大小是232K：

232Kbuild-qemu-virt-a15-test/lk.elf

LittlKernel可以跑起来：

wfg/c/fuchsia/lk％qemu-system-arm-machine virt-cpu cortex-a15-m 1-smp 1-kernel build-qemu-virt-a15-test/lk.elf-nographic

welcome to lk/MP

boot args 0x0 0x00x00x0

INIT：cpu 0，calling hook 0x8002e7b5（version）at level 0x3ffff，flags 0x1

version：

arch：ARM

platform：QEMU_VIRT

target：QEMU_VIRT

project：QEMU_VIRT_A15_TEST

buildid：F8Q5R_LOCAL

INIT：cpu 0，calling hook 0x8002fae9（vm_preheap）at level 0x3ffff，flags 0x1

initializing heap

calling constructors

INIT：cpu 0，calling hook 0x8002fb2d（vm）at level 0x50000，flags 0x1

initializing mp

initializing threads

initializing timers

initializing ports

creating bootstrap completion thread

top of bootstrap2（）

INIT：cpu 0，calling hook 0x8002c681（pktbuf）at level 0x70000，flags 0x1

pktbuf：creating 256 pktbuf entries of size 1536（total 393216）

INIT：cpu 0，calling hook 0x8002e8a9（virtio）at level 0x70000，flags 0x1

releasing 0 secondary cpus

initializing platform

initializing target

calling apps_init（）

starting app inetsrv

starting internet servers

starting app shell

entering main console loop

]help

command list：

page_alloc：page allocator debug commands

heap：heap debug commands

gfx：gfx commands

help：this list

test：test the command processor

history：command history

bio：block io debug commands

vmm：virtual memory manager

…

Regards，

Fengguang

吴：Fuchsia/Magenta有一点非常重要：它不是一个POSIX兼容系统，如果这是个迷你的IoT专用OS，就不是什么问题，如果它想要在手机、桌面系统发展，则意味从零开始，无处借力。因为不兼容POSIX则难以利用现有的庞大软件生态，什么都得从头研发。

作为对比，在嵌入式设备和手机上都能跑的QNX是POSIX兼容系统。

陆：峰光，你质疑Google的Fuchsia的意见，可能会遇到不同意见，如有人说IoT系统很难通用化场景太复杂。我看Fuchsia似乎不是一个通用OS，也不像碎片化的专用IoT OS，如果Google能够模块化设计，似乎更有前途。