關于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能夠模塊化設計，似乎更有前途。