陸首群教授與吳峰光博士

關(guān)于Linux迎接挑戰(zhàn)的序列對話

中國開源軟件推進(jìn)聯(lián)盟專家委員會(huì)

The Sequence Dialogue to Meet the Challenge in Regard to Linux

Linux創(chuàng)始人Linus Torvalds說：Android就是Linux操作系統(tǒng)，今天全球持有Android智能手機(jī)的人已超過20億；全球500臺運(yùn)行速度最快的超級計(jì)算機(jī)80％采用Linux；在網(wǎng)絡(luò)領(lǐng)域，由中國企業(yè)（中移動(dòng).華為）主導(dǎo)的基于Linux的主流開源項(xiàng)目Open-O最近創(chuàng)新成功，該項(xiàng)目涉及網(wǎng)絡(luò)管理和編排領(lǐng)域的創(chuàng)新，它將重新定義SDN的基礎(chǔ)架構(gòu)，指導(dǎo)全球一些大規(guī)模通信網(wǎng)絡(luò)的部署和管理；甚至連微軟的云計(jì)算平臺今年8月也引入紅帽的Linux（企業(yè)版）操作系統(tǒng)。Linux無處不在，但遭遇挑戰(zhàn)。今發(fā)表中國開源軟件推進(jìn)聯(lián)盟名譽(yù)主席陸首群教授和Linux基金會(huì)Linux大規(guī)模自動(dòng)化測試專家吳峰光博士對話：“關(guān)于Linux迎接挑戰(zhàn)的序列對話（之一、之二、之三）。

（陸首群教授，中國開源軟件推進(jìn)聯(lián)盟名譽(yù)主席，以下簡稱“陸”；吳峰光博士，Linux基金會(huì)Linux大規(guī)模自動(dòng)化測試專家，以下簡稱“吳”）

第一篇

陸：今天要跟你討論的問題主要是Linux在發(fā)展中遇到了哪些挑戰(zhàn)，我準(zhǔn)備給Linux基金會(huì)創(chuàng)始人Linus Torvalds寫信，問他有哪些應(yīng)對措施。在寫信前先跟你討論：

第一個(gè)問題：有人說Linux的發(fā)展似乎不是從用戶的需求出發(fā)的，而是來自開發(fā)者的創(chuàng)意。如果長此下去，是否會(huì)使Linux發(fā)展迷失方向？

第二個(gè)問題：Linux開發(fā)支持基于X86的主流架構(gòu)，Linux雖然也支持多架構(gòu)如arm、mips…等，但其他架構(gòu)是非主流的，支持力度恐怕要弱，面對PC向移動(dòng)繼而又向IoT發(fā)展形勢，長期以X86作為支持的主流架構(gòu)是否會(huì)阻礙Linux的發(fā)展？

第三個(gè)問題：最近谷歌開發(fā)了用于物聯(lián)網(wǎng)（IoT）領(lǐng)域新的操作系統(tǒng)開源的Fuchsia，其特點(diǎn)是小型化和實(shí)時(shí)性，而作為通用操作系統(tǒng)的Linux（大量用于移動(dòng)終端也可用于桌面系統(tǒng)）相對來說功能多，結(jié)構(gòu)復(fù)雜、體積臃腫，難以做到小型化實(shí)時(shí)性，但I(xiàn)oT是當(dāng)前和未來影響極大的大市場，Linux（用于IoT）是否要迎接挑戰(zhàn)呢？

吳：陸主席，您好！

關(guān)于您電話中提到的三個(gè)問題，我的感覺是第一個(gè)問題是虛的，第三個(gè)問題是實(shí)實(shí)在在的，第二個(gè)問題很大程度上根源于arm廠商和市場的特質(zhì)。

1、開發(fā)者與用戶需求問題

Linux開發(fā)者以用戶需求為依據(jù)，大體上可以分為兩類：

●-Linux代碼貢獻(xiàn)者：主要是各個(gè)下游廠商的開發(fā)者，或者團(tuán)體/個(gè)人用戶，他們是需求的提出者和實(shí)現(xiàn)者，是主要推動(dòng)力量；

●-Linux維護(hù)者：站在Linux Kernel長遠(yuǎn)發(fā)展的角度，審查代碼，改進(jìn)架構(gòu)，確保質(zhì)量，性能和長期可維護(hù)性。維護(hù)者對于各個(gè)廠商基本持兼容并包的態(tài)度，其立場一般是中立的從技術(shù)角度看問題。這樣的體系基本上是合理的，體現(xiàn)了Linux社區(qū)驅(qū)動(dòng)的性質(zhì)：需求主要來源于社區(qū)力量，體現(xiàn)為企業(yè)/個(gè)人用戶的代碼提交。

2、X86/arm問題

如1.所述，Linus及其維護(hù)者團(tuán)隊(duì)努力維持其自主性，鼓勵(lì)各廠商的開發(fā)者以“獨(dú)立貢獻(xiàn)者”（Individual Contributor）的方式貢獻(xiàn)代碼。

Linus對X86支持的好，源自于兩個(gè)主要因素：

●-X86是主流硬件，大部分的用戶和開發(fā)者都在用X86，自然而然它的功能、性能、bug反饋都有先天優(yōu)勢。

陸首群，曾任北京電子振興辦公室主任兼北京市政府電子工業(yè)辦公室主任；中國長城計(jì)算機(jī)集團(tuán)公司董事長，中國吉通通信公司名譽(yù)董事長，中國聯(lián)通通信公司籌建負(fù)責(zé)人（之一），首都信息發(fā)展股份有限公司名譽(yù)董事長；曾任國務(wù)院信息辦常務(wù)副主任（主持組織金橋、金卡、金關(guān)、金稅工程頂層設(shè)計(jì)，主持籌建中國首批四大互聯(lián)網(wǎng)），中國工業(yè)經(jīng)濟(jì)聯(lián)合會(huì)副會(huì)長；曾應(yīng)聘任中國人民銀行、航天工業(yè)部、廣電部信息化高級顧問。

●-X86開發(fā)較為有序，ARM相對渙散。特別是在Linario組織出現(xiàn)之前。

ARM陣營里的廠商競爭多于合作，導(dǎo)致ARM這個(gè)體系結(jié)構(gòu)的維護(hù)狀態(tài)跟它擁有的開發(fā)者數(shù)量不相稱。很典型的就是ARM里的子架構(gòu)非常多，高達(dá)74個(gè)，每個(gè)廠商自搞一套，代碼互相拷貝粘貼，大同而小異。造成維護(hù)的噩夢，Linus對此深惡痛絕，屢屢批評和督促ARM開發(fā)者向X86開發(fā)者學(xué)習(xí)。Linaro組織的出現(xiàn)就是朝這個(gè)方向的一個(gè)重要努力。ARM架構(gòu)的代碼修改量很長時(shí)間以來都比X86架構(gòu)的修改量大得多，代碼絕對數(shù)量也更大：ARM，380K代碼行數(shù)；X86，260K代碼行數(shù)。這說明ARM不缺開發(fā)者，可惜各自為戰(zhàn)的成分多了些。除此之外，各Android手機(jī)廠商開發(fā)的數(shù)量龐大的代碼，大部分都沒往上游推。主要是有很強(qiáng)大的產(chǎn)品快速上市的壓力。前后產(chǎn)品之間的代碼復(fù)用都很難。相比而言，服務(wù)器廠商在產(chǎn)品開發(fā)和生態(tài)培育上更有節(jié)奏感，能長期穩(wěn)健投入，建設(shè)起一個(gè)體系。

Linux從1995年發(fā)布1.2.0開始就支持多種硬件架構(gòu)了。這時(shí)候的Linux還處于幼兒階段，代碼簡單。這么早就引入多體系架構(gòu)的支持，意味著Linux從設(shè)計(jì)上對多架構(gòu)的支持是完善和具有前瞻性的。如果某些架構(gòu)表現(xiàn)不好，大概只能從這個(gè)體系架構(gòu)的廠商那里去找原因了。

3、IoT

IoT對于Linux的確是一大挑戰(zhàn)。主要是大小和延遲兩方面的挑戰(zhàn)。一方面是因?yàn)長inux的成功發(fā)展導(dǎo)致了臃腫和復(fù)雜。另一方面是Linux是社區(qū)驅(qū)動(dòng)的，來自于嵌入式廠商的驅(qū)動(dòng)力量偏于薄弱。我倡議相關(guān)的嵌入式廠商和開發(fā)者采取切實(shí)的行動(dòng)，貢獻(xiàn)自己力所能及的力量，讓Linux在小設(shè)備上跑得更好。社區(qū)的創(chuàng)造源泉來自于包括你我在內(nèi)的每個(gè)參與者。像一個(gè)嵌入式系統(tǒng)。我除了想與你探討Linux和Fuchsia的關(guān)系外，還請你搜集一些具體數(shù)據(jù)（我本人也搜集中）。我感到有興趣的是Linux如何應(yīng)對挑戰(zhàn)，首先想聽你的意見。

吳：陸主席，您好！

關(guān)于Linux/Fuchsia的調(diào)研如下，還有若干問題我后面繼續(xù)補(bǔ)充。Linux在IoT領(lǐng)域面臨兩個(gè)基本挑戰(zhàn)：1）內(nèi)核大小，2）響應(yīng)延遲。有些設(shè)備太小沒法跑Linux；有些設(shè)備要求低延遲也沒法用Linux。對于這些設(shè)備，為它們專門設(shè)計(jì)的各種IoTOS會(huì)是恰當(dāng)?shù)倪x擇。Linux的設(shè)計(jì)目標(biāo)是一個(gè)通用操作系統(tǒng)，大量技術(shù)上的Design Trade Off就會(huì)往該目標(biāo)上傾斜，再加支持上非常多的功能而導(dǎo)致的復(fù)雜性，要克服上述兩個(gè)挑戰(zhàn)相當(dāng)不容易。實(shí)際上Linux內(nèi)核的最小大小隨著功能的增多一直在增長，見下圖。

來源是http://events.linuxfoundation.org/sites/events/files/slid es/tiny.pdf。Linux與RTOS的延遲比較，見下圖，

第二篇

陸：最近Google開發(fā)新的操作系統(tǒng)Fuchsia，其內(nèi)核Magenta（基于Little Kernel，LK），與Android（Linux OS）及Linux（Kernel）有什么差別呢？它的應(yīng)用范圍是IoT、移動(dòng)終端、桌面系統(tǒng)。我看它主要用于IoT，說要擴(kuò)展到桌面操作系統(tǒng)領(lǐng)域，似乎有點(diǎn)吹牛。我還是認(rèn)為，Linux和Fuchsia應(yīng)用范圍是各司其職。它與Linux操作系統(tǒng)最大的區(qū)別是它能做到小型化和實(shí)時(shí)操作，Linux作為一個(gè)通用操作系統(tǒng)，代碼影像尺寸（內(nèi)存空間）愈來愈大，響應(yīng)時(shí)間愈來愈長（難以實(shí)時(shí)操作）。時(shí)代在變化，由PC（桌面系統(tǒng)）而移動(dòng)（終端）繼而物聯(lián)網(wǎng)（IoT），IoT是“第四次工業(yè)革命”的主要領(lǐng)域。Linux的發(fā)展是否也會(huì)與時(shí)俱進(jìn)？Linux有沒有瘦身化的目標(biāo)？你電話中告訴我，Linux也有精簡版，恐怕這時(shí)尚難做到小型化和實(shí)時(shí)操作。還有一點(diǎn)，F(xiàn)uchsia還不至于小到

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

當(dāng)然Linux也在改進(jìn)，比如這份技術(shù)白皮書：

Linux As a Real-Time Operation System 11/2005

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

對于硬件能力稍強(qiáng)的設(shè)備，相應(yīng)的會(huì)對軟件能力和生態(tài)有更高的要求和依賴。Linux應(yīng)當(dāng)發(fā)揮積極的作用，把這些設(shè)備支持好。但是持續(xù)增長的內(nèi)核大小說明Linux對它們的支持正在惡化。說明在Linux社區(qū)中缺少足夠的力量來監(jiān)測和優(yōu)化內(nèi)核大小。問題可能在于：手機(jī)及嵌入式領(lǐng)域的廠家投入了大量的人力來讓Linux在自家的平臺上跑的好，但是一般來說缺乏熱情，把產(chǎn)品代碼整理干凈，變成質(zhì)量高通用性好的代碼，并把它推入上游Linux的代碼庫。桌面及服務(wù)器廠商的態(tài)度就是（比如Intel、Red Hat）upstream first，先把代碼貢獻(xiàn)給上游，然后在自家產(chǎn)品中采用或移植（Backport）。兩種態(tài)度造成的差別就是：Linux對桌面和服務(wù)器支持相當(dāng)好，然而在嵌入式領(lǐng)域的表現(xiàn)不盡如人意。據(jù)我所知Linux下游廠商的開發(fā)者數(shù)量要比上游維護(hù)者大兩個(gè)數(shù)量級。他們作為最了解需求，掌握最多開發(fā)者的大客戶不貢獻(xiàn)代碼，上游維護(hù)者想要迎合用戶需求也難。Linus及其維護(hù)團(tuán)隊(duì)主要職責(zé)還是在于質(zhì)量把關(guān)和確保架構(gòu)合理。大體上Linux Kernel的發(fā)展方向是被各類用戶推著走的。哪一類（廠商）用戶比較給力，Linux在哪方面就發(fā)展的好。

第三篇

陸：峰光，請幫忙查一下Fuchsia/Magenta/Little Kernel的內(nèi)存，以及Android/Linux（Kernel）的內(nèi)存。我有其它渠道也在查，但我希望獲得你的數(shù)據(jù)和評說。

吳：陸主席，您好！

Fuchsia/Magenta跑起來需要多少內(nèi)存還不清楚。我需要編譯看看。

代碼量是知道的：

代碼行數(shù)（SLOC）人年項(xiàng)目歷史

Linux v4.814M47351991 Linux 0.018k1.81991 LittleKernel75k202008 Magenta103k27最近公開，估計(jì)內(nèi)部研發(fā)有一兩年了

如果把第三方代碼也算進(jìn)去：LittleKernel506k138

Magenta294k78

kernel size ROM sizeRAM size

LittleKernel15-20 KB（映像文件）

Zephyr8-512 KB（映像文件）10 KB（內(nèi)存需求量）（由Intel/WindRiver捐獻(xiàn)給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迷你桌面系統(tǒng)：

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編譯出來了，整個(gè)內(nèi)核加用戶態(tài)映像文件大小是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

這是不帶圖形功能的。不過跑不起來，死機(jī)了：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有一點(diǎn)非常重要：它不是一個(gè)POSIX兼容系統(tǒng)，如果這是個(gè)迷你的IoT專用OS，就不是什么問題，如果它想要在手機(jī)、桌面系統(tǒng)發(fā)展，則意味從零開始，無處借力。因?yàn)椴患嫒軵OSIX則難以利用現(xiàn)有的龐大軟件生態(tài)，什么都得從頭研發(fā)。

作為對比，在嵌入式設(shè)備和手機(jī)上都能跑的QNX是POSIX兼容系統(tǒng)。

陸：峰光，你質(zhì)疑Google的Fuchsia的意見，可能會(huì)遇到不同意見，如有人說IoT系統(tǒng)很難通用化場景太復(fù)雜。我看Fuchsia似乎不是一個(gè)通用OS，也不像碎片化的專用IoT OS，如果Google能夠模塊化設(shè)計(jì)，似乎更有前途。