0
  • 聊天消息
  • 系統(tǒng)消息
  • 評(píng)論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線(xiàn)課程
  • 觀看技術(shù)視頻
  • 寫(xiě)文章/發(fā)帖/加入社區(qū)
會(huì)員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識(shí)你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

Linux內(nèi)核維護(hù)者的真相與誤解

Linux愛(ài)好者 ? 來(lái)源:Linux News搬運(yùn)工 ? 作者:Linux News搬運(yùn)工 ? 2021-03-03 15:28 ? 次閱讀

自 2020 年 1 月發(fā)布 5.5 內(nèi)核之后,到現(xiàn)在已經(jīng)有近 87,000 個(gè) patch,來(lái)自于近 4600 名開(kāi)發(fā)者,都被合并到 mainline 倉(cāng)庫(kù)中了。review 所有這些 patch 的工作,對(duì)于愿意花時(shí)間的內(nèi)核開(kāi)發(fā)者來(lái)說(shuō)也都是一項(xiàng)艱巨的任務(wù),所以是否要接受合并 patch,這個(gè)決定權(quán)就被委托給了各個(gè)子系統(tǒng)的維護(hù)者(maintainer)來(lái)代理決定,他們每個(gè)人都對(duì)內(nèi)核中這一部分的改動(dòng)具有部分或者完整的決定權(quán)。

這些維護(hù)者們就被記錄在一個(gè)叫 MAINTAINERS 的文件中(當(dāng)然是這個(gè)名字)。但是,MAINTAINERS 文件也需要維護(hù),它能很好地反映現(xiàn)實(shí)情況嗎?MAINTAINERS 文件的存在目的,并不僅僅是為了讓大家給維護(hù)者點(diǎn)贊。開(kāi)發(fā)者們需要用它來(lái)確定該把 patch 發(fā)到哪里。

get_maintainer.pl 腳本通過(guò)查看這個(gè) patch 修改了的文件,就可以生成一系列郵件地址來(lái)發(fā)送 patch,從而讓這一過(guò)程變得更加自動(dòng)化。如果這個(gè)文件中有錯(cuò)誤信息的話(huà),就可能會(huì)讓 patch 發(fā)送到錯(cuò)誤的地方去,所以我們需要這個(gè)文件能保持更新。

最近,編者收到 Jakub Kicinski 的建議,他認(rèn)為可以比較 一下 MAINTAINERS 中的各個(gè)條目和現(xiàn)實(shí)世界中的工作的吻合程度,應(yīng)該能得到一些線(xiàn)索。于是折騰了一會(huì)兒 Python 之后,我們就得到了一個(gè)新的分析腳本。

Digging into MAINTAINERS

統(tǒng)計(jì)下來(lái),MAINTAINERS 文件中已經(jīng)列出了 2280 個(gè) "subsystems (子系統(tǒng))"。每一個(gè)子系統(tǒng)都包括一個(gè)它所涵蓋的文件和目錄列表。我們可以查看這些文件的 commit 信息來(lái)這個(gè)子系統(tǒng)中都有誰(shuí)在進(jìn)行工作。

撰寫(xiě) patch 顯然屬于工作內(nèi)容之一,但其他活動(dòng)也得算,比如處理 patch (可以從 Signed-off-by tag 來(lái)得到這個(gè)信息) 或 review patch (根據(jù) Reviewed-by 或 Acked-by)。

我們犧牲了一些 CPU 挖礦的時(shí)間,得到了一個(gè)大概統(tǒng)計(jì)值,也就是各個(gè)子系統(tǒng)中明確列出的維護(hù)者最后一次在該子系統(tǒng)中實(shí)際做了有效工作的時(shí)間是什么時(shí)候。

對(duì)于那些想看細(xì)節(jié)的人來(lái)說(shuō),可以直接看這個(gè)完整結(jié)果(https://lwn.net/Articles/842419/)。

不過(guò),我們可以縮小數(shù)據(jù)范圍,在這個(gè)文件中挑選出一些我們更感興趣的內(nèi)容。例如,有 367 個(gè)子系統(tǒng)在整個(gè) Git 歷史中都沒(méi)有維護(hù)者,或維護(hù)者從未出現(xiàn)過(guò)(沒(méi)有包括那些沒(méi)有文件的 "子系統(tǒng)"–見(jiàn)下文)。

在這些子系統(tǒng)中,很多已經(jīng)過(guò)了它本身的黃金時(shí)期,比如現(xiàn)在 3c59x 網(wǎng)卡維護(hù)者根本沒(méi)有多少工作可做。網(wǎng)絡(luò)開(kāi)發(fā)人員也不會(huì)收到很多 ATM 的 patch 了,Palm Treo 也不需要有多少支持工作了,蘋(píng)果最近也很少發(fā)布基于 M68k 的系統(tǒng)了,Arm 軟驅(qū)(floppy drive)也沒(méi)有多少人還在使用了,S3 Savage 顯卡也不再是以前人們所必備的設(shè)備了。

這幾百項(xiàng)中,很多可能都代表著可以完全刪除的代碼。類(lèi)似的結(jié)論也可以從另一個(gè)列表中得到 (https://lwn.net/Articles/842424/),那個(gè)列表中都是沒(méi)有列出維護(hù)者的子系統(tǒng)。當(dāng)然,其中一些子系統(tǒng)本身也不太對(duì)頭,有一個(gè)子系統(tǒng)簡(jiǎn)單地命名為 "ABI/API",指向了 linux-api 郵件列表。實(shí)際上有一個(gè)文件是與這個(gè) "子系統(tǒng) " 相關(guān)的,kernel/sys_ni.c,這個(gè)文件會(huì)對(duì)那些未實(shí)現(xiàn)的系統(tǒng)調(diào)用進(jìn)行處理。因此,這個(gè)條目的存在價(jià)值,是為了讓開(kāi)發(fā)者在添加新的系統(tǒng)調(diào)用時(shí)會(huì)抄送 linux-api 郵件列表。

"Arm subarchitectures " 條目也是類(lèi)似情況。一些無(wú)維護(hù)者的子系統(tǒng),比如 framebuffer 層,可能后續(xù)會(huì)有人愿意接手從而復(fù)活。

reiserfs 文件系統(tǒng)缺乏維護(hù)者,但似乎仍有一些用戶(hù)。其他的子系統(tǒng),比如 DECnet 或 Matrox framebuffer,可能最好的處理就是不去管它了(或干脆刪除掉)。

MAINTAINERS 文件中列出的一些 "子系統(tǒng)" 沒(méi)有任何文件需要修改。

一個(gè)有趣的例子是 "embedded Linux",據(jù)說(shuō)由 Paul Gortmaker、Matt Mackall 和 David Woodhouse 維護(hù)。鑒于嵌入式 Linux 的成功,我們都認(rèn)為他們的工作非常出色。"device number registry" 聲稱(chēng)是有維護(hù)的,但這里只包含一個(gè)鏈接,指向一個(gè)不存在的網(wǎng)頁(yè)。

"disk geometry and partition handling" 這一條中的 URL 仍然有效,但這些網(wǎng)頁(yè)似乎已經(jīng)有十多年沒(méi)有更新了,可以看出最近 Zip 驅(qū)動(dòng)器的 geometry 并沒(méi)有什么進(jìn)展。

man page 這些手冊(cè)頁(yè)面倒是有積極維護(hù)的,但它們不在內(nèi)核代碼樹(shù)中。

Help needed

從目前的結(jié)果可以得出幾個(gè)結(jié)論。一個(gè)是很多內(nèi)核子系統(tǒng)現(xiàn)在并不是真的需要有人來(lái)維護(hù),相反,其中一些可能需要被刪除掉。另一個(gè)結(jié)論是,也許 MAINTAINERS 文件本身需要清理一下。但還有一個(gè)有價(jià)值的問(wèn)題,那就是從這些數(shù)據(jù)是否可以看出是否有一些子系統(tǒng)從新的維護(hù)者中獲益匪淺的呢?

為了回答這個(gè)問(wèn)題,我們又花費(fèi)了一些本來(lái)可以用來(lái)挖礦的 CPU 時(shí)間,來(lái)尋找符合這些標(biāo)準(zhǔn)的子系統(tǒng)。

沒(méi)有列出維護(hù)者,或者所謂的維護(hù)者已經(jīng)在該子系統(tǒng)中至少 6 個(gè)月沒(méi)有活動(dòng)了。

自 2020 年 1 月發(fā)布 5.5 內(nèi)核以來(lái),至少有 50 個(gè)提交跟這個(gè)子系統(tǒng)有關(guān)。

這個(gè)搜索的目的是找出那些仍在進(jìn)行某種活躍開(kāi)發(fā),但沒(méi)有活躍的、明確指定的子系統(tǒng)。

搜索結(jié)果可以分為幾類(lèi)。有些 MAINTAINERS 的條目中包含了大量的文件,使得 commit 數(shù)量看起來(lái)比真實(shí)情況要多了不少。

例如,名為 "ASYNCHRONOUS TRANSFERS/TRANSFORMS (IOAT) API "的子系統(tǒng)跟 drivers/dma 下的所有文件都有關(guān),"DMA GENERIC OFFLOAD ENGINE SUBSYSTEM" 也包含這些文件。

該子系統(tǒng)則由 Vinod Koul 積極維護(hù)。有兩個(gè)子系統(tǒng)屬于這一類(lèi),在下面的表格中,"Activity" 列表示維護(hù)者最后一次我們看到他的活動(dòng)時(shí)間(如果有的話(huà)),而 "Commits" 則顯示了自 5.5 以來(lái)影響到這個(gè)子系統(tǒng)的 commit 次數(shù)。

Subsystem Activity Commits
ASYNCHRONOUS TRANSFERS/TRANSFORMS (IOAT) API —— 536
HISILICON NETWORK SUBSYSTEM DRIVER 2019-11-16 258

這些子系統(tǒng)或者不是一個(gè)單獨(dú)的實(shí)體(entity),或者應(yīng)該減少其覆蓋的文件清單,要以符合現(xiàn)實(shí)情況。

還有一些子系統(tǒng)的維護(hù)者使用的是公司電子郵件別名。比如 "DIALOG SEMICONDUCTOR DRIVERS" 的維護(hù)者是 support.opensource@diasemi.com,這個(gè)地址顯然不會(huì)出現(xiàn)在任何實(shí)際的 patch commit 中。不過(guò)在該子系統(tǒng)內(nèi)看進(jìn)去的話(huà),可以看到許多來(lái)自 diasemi.com 郵件地址的許多 review,所以該子系統(tǒng)不能說(shuō)是真的沒(méi)人維護(hù)。

這個(gè)類(lèi)別包含:

Subsystem Activity Commits
DIALOG SEMICONDUCTOR DRIVERS —— 120
QUALCOMM ATHEROS ATH9K WIRELESS DRIVER —— 65
WOLFSON MICROELECTRONICS DRIVERS —— 146

與之相關(guān)的是有些子系統(tǒng)的維護(hù)者信息是過(guò)時(shí)的,指定的維護(hù)者并不活躍,但往往是來(lái)自同一公司的其他人接替了他的工作,并承擔(dān)事實(shí)上的維護(hù)工作。

這些包括:

Subsystem Activity Commits
HISILICON NETWORK SUBSYSTEM 3 DRIVER (HNS3) 2019-11-16 234
HISILICON SECURITY ENGINE V2 DRIVER (SEC2) 2020-06-18 55
LINUX FOR POWER MACINTOSH 2018-10-19 71
MELLANOX ETHERNET INNOVA DRIVERS —— 93
MELLANOX MLX4 IB driver —— 70
OMAP HWMOD DATA 2016-06-10 102
QCOM AUDIO (ASoC) DRIVERS 2018-05-21 125
TEGRA I2C DRIVER 2018-05-30 56

最后,還有一些子系統(tǒng)似乎真的缺少維護(hù)者,它們通常的 commit 是由其他的子系統(tǒng)維護(hù)者來(lái)合并,或者是通過(guò)少數(shù)幾個(gè)終極維護(hù)者來(lái)最終合入的。

它們是:

Subsystem Activity Commits
ARM/UNIPHIER ARCHITECTURE —— 73
DRBD DRIVER 2018-12-20 51
FRAMEBUFFER LAYER —— 402
HMM - Heterogeneous Memory Management 2020-05-19 54
I2C SUBSYSTEM HOST DRIVERS —— 434
MARVELL MVNETA ETHERNET DRIVER 2018-11-23 65
MEDIA DRIVERS FOR RENESAS - VIN 2019-10-10 56
MUSB MULTIPOINT HIGH SPEED DUAL-ROLE CONTROLLER 2020-06-24 54
NFC SUBSYSTEM —— 72
PROC FILESYSTEM —— 171
PROC SYSCTL 2020-06-08 51
QLOGIC QLGE 10Gb ETHERNET DRIVER 2019-10-04 77
STAGING - REALTEK RTL8188EU DRIVERS 2020-07-15 121
STMMAC ETHERNET DRIVER 2020-05-01 174
UNIVERSAL FLASH STORAGE HOST CONTROLLER DRIVER —— 277
USB NETWORKING DRIVERS —— 119
X86 PLATFORM DRIVERS - ARCH —— 119

對(duì)于一直關(guān)注相關(guān)領(lǐng)域的人來(lái)說(shuō),上面的列表并不出乎預(yù)料。frameebuffer 子系統(tǒng)是一個(gè)已知有問(wèn)題的領(lǐng)域,由于缺乏維護(hù),"soft scrollback" 功能最近就被從 framebuffer 驅(qū)動(dòng)中移除了。

不少人仍然需要使用這段代碼,但它越來(lái)越難以與內(nèi)核的圖形驅(qū)動(dòng)集成起來(lái)使用,很少有人有興趣去深入研究它。事實(shí)上,I2C host driver 確實(shí)有一個(gè)事實(shí)上的維護(hù)者,它就是 Wolfram Sang,他也維護(hù)著 core I2C 子系統(tǒng)。他一直希望有人能幫助他維護(hù)這些驅(qū)動(dòng)程序,但似乎沒(méi)有人愿意幫助他,所以他在有時(shí)間的時(shí)候就也負(fù)責(zé)維護(hù)這些驅(qū)動(dòng)程序。

/proc 是一個(gè)有趣的例子,每個(gè)人都依賴(lài)它,但沒(méi)有人負(fù)責(zé)維護(hù)它。HMM 也很有趣,創(chuàng)建者當(dāng)初花了很多精力來(lái)把 HMM 功能合入 mainline,但現(xiàn)在似乎轉(zhuǎn)向去忙其他事情了。

以上這些地方,看起來(lái)都是有抱負(fù)的內(nèi)核開(kāi)發(fā)者可以參與進(jìn)來(lái)提供幫助的地方。那么那些在 MAINTAINERS 文件中沒(méi)有記錄的子系統(tǒng)呢?如果我們用快速腳本來(lái)查找一下內(nèi)核樹(shù)中所有的未被 MAINTAINERS 文件包含的文件,我們得到的文件列表包含超過(guò) 2800 個(gè)文件。其中自然包括 MAINTAINERS 文件本身。其余的絕大多數(shù)都是 include/下的頭文件,其中大部分可能都有維護(hù)者,應(yīng)該添加到 MAINTAINER 文件中相應(yīng)的條目下。

不過(guò)令人沮喪的是,在 kernel/目錄下有 72 個(gè)文件沒(méi)有列出維護(hù)者。這當(dāng)然不是現(xiàn)實(shí)情況。SYSV IPC 代碼是沒(méi)有維護(hù)者的,這反映了它普遍不受歡迎。

其余大部分未維護(hù)的文件都在 tools/ 或 samples/ 目錄下。比較難找出來(lái)的是 MAINTAINERS 中號(hào)稱(chēng)會(huì)包含的文件中,其實(shí)有一些并不是由指定的人維護(hù)的。這種情況經(jīng)常出現(xiàn)在那些指定包含整個(gè)目錄樹(shù)的條目中。例如,編者被列為需要處理 Documentation/目錄,但肯定不能說(shuō)我真的是在 "維護(hù)" 這么多文件。類(lèi)似的情況在內(nèi)核樹(shù)中很多地方都有。

如果有人希望從這些數(shù)據(jù)中得出一些整體性的結(jié)論,那么可能會(huì)是這些:MAINTAINERS 文件肯定有一些黑暗的角落,這些角落本身也可能需要一些維護(hù)(其中一些已經(jīng)在做了)。內(nèi)核中一些缺乏維護(hù)者的部分,仍然是可以使用的,而另一些則已經(jīng)過(guò)于古老都不需要維護(hù)了。不過(guò),大多數(shù)情況下,內(nèi)核中的子系統(tǒng)都有指定的維護(hù)者,而且他們中的大多數(shù)人至少都在努力維護(hù)他們負(fù)責(zé)的代碼。The situation could be a lot worse。

責(zé)任編輯:lq

聲明:本文內(nèi)容及配圖由入駐作者撰寫(xiě)或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場(chǎng)。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問(wèn)題,請(qǐng)聯(lián)系本站處理。 舉報(bào)投訴
  • Linux
    +關(guān)注

    關(guān)注

    87

    文章

    11199

    瀏覽量

    208691
  • 自動(dòng)化
    +關(guān)注

    關(guān)注

    29

    文章

    5478

    瀏覽量

    78981
  • python
    +關(guān)注

    關(guān)注

    55

    文章

    4766

    瀏覽量

    84362

原文標(biāo)題:Linux 內(nèi)核維護(hù)者的真相與誤解

文章出處:【微信號(hào):LinuxHub,微信公眾號(hào):Linux愛(ài)好者】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。

收藏 人收藏

    評(píng)論

    相關(guān)推薦

    deepin社區(qū)亮相第19屆中國(guó)Linux內(nèi)核開(kāi)發(fā)大會(huì)

    中國(guó) Linux 內(nèi)核開(kāi)發(fā)大會(huì),作為中國(guó) Linux 內(nèi)核領(lǐng)域最具影響力的峰會(huì)之一,一直以來(lái)都備受矚目。
    的頭像 發(fā)表于 10-29 16:35 ?306次閱讀

    linux驅(qū)動(dòng)程序如何加載進(jìn)內(nèi)核

    Linux系統(tǒng)中,驅(qū)動(dòng)程序是內(nèi)核與硬件設(shè)備之間的橋梁。它們?cè)试S內(nèi)核與硬件設(shè)備進(jìn)行通信,從而實(shí)現(xiàn)對(duì)硬件設(shè)備的控制和管理。 驅(qū)動(dòng)程序的編寫(xiě) 驅(qū)動(dòng)程序的編寫(xiě)是Linux驅(qū)動(dòng)開(kāi)發(fā)的基礎(chǔ)。在編
    的頭像 發(fā)表于 08-30 15:02 ?336次閱讀

    Linux內(nèi)核測(cè)試技術(shù)

    Linux 內(nèi)核Linux操作系統(tǒng)的核心部分,負(fù)責(zé)管理硬件資源和提供系統(tǒng)調(diào)用接口。隨著 Linux 內(nèi)核的不斷發(fā)展和更新,其復(fù)雜性和代碼規(guī)
    的頭像 發(fā)表于 08-13 13:42 ?403次閱讀
    <b class='flag-5'>Linux</b><b class='flag-5'>內(nèi)核</b>測(cè)試技術(shù)

    Linux內(nèi)核中的頁(yè)面分配機(jī)制

    Linux內(nèi)核中是如何分配出頁(yè)面的,如果我們站在CPU的角度去看這個(gè)問(wèn)題,CPU能分配出來(lái)的頁(yè)面是以物理頁(yè)面為單位的。也就是我們計(jì)算機(jī)中常講的分頁(yè)機(jī)制。本文就看下Linux內(nèi)核是如何管
    的頭像 發(fā)表于 08-07 15:51 ?213次閱讀
    <b class='flag-5'>Linux</b><b class='flag-5'>內(nèi)核</b>中的頁(yè)面分配機(jī)制

    歡創(chuàng)播報(bào) 華為宣布鴻蒙內(nèi)核已超越Linux內(nèi)核

    1 華為宣布鴻蒙內(nèi)核已超越Linux內(nèi)核 ? 6月21日,在華為開(kāi)發(fā)大會(huì)上, HarmonyOS NEXT(鴻蒙NEXT)——真正獨(dú)立于安卓和iOS的鴻蒙操作系統(tǒng),正式登場(chǎng)。這是Ha
    的頭像 發(fā)表于 06-27 11:30 ?752次閱讀

    算能全系列RISC-V處理器進(jìn)入PLCT實(shí)驗(yàn)室6.6內(nèi)核維護(hù)工程

    Linux內(nèi)核6.6LTS分支的升級(jí)并進(jìn)行長(zhǎng)期維護(hù);與此同時(shí),繼續(xù)推動(dòng)算能RISC-V相關(guān)補(bǔ)丁進(jìn)入Linux內(nèi)核上游(upstream)。
    的頭像 發(fā)表于 05-22 08:33 ?826次閱讀
    算能全系列RISC-V處理器進(jìn)入PLCT實(shí)驗(yàn)室6.6<b class='flag-5'>內(nèi)核</b><b class='flag-5'>維護(hù)</b>工程

    使用 PREEMPT_RT 在 Ubuntu 中構(gòu)建實(shí)時(shí) Linux 內(nèi)核

    盟通技術(shù)干貨構(gòu)建實(shí)時(shí)Linux內(nèi)核簡(jiǎn)介盟通技術(shù)干貨Motrotech如果需要在Linux中實(shí)現(xiàn)實(shí)時(shí)計(jì)算性能,進(jìn)而有效地將Linux轉(zhuǎn)變?yōu)镽TOS,那么大多數(shù)發(fā)行版都可以打上名為PREE
    的頭像 發(fā)表于 04-12 08:36 ?2066次閱讀
    使用 PREEMPT_RT 在 Ubuntu 中構(gòu)建實(shí)時(shí) <b class='flag-5'>Linux</b> <b class='flag-5'>內(nèi)核</b>

    Ubuntu 24.04 LTS選用Linux 6.8為默認(rèn)內(nèi)核

    關(guān)于Ubuntu 24.04 LTS使用何種內(nèi)核版本,一直備受關(guān)注。Canonical工程師Andrea Righi昨日宣布,Ubuntu 24.04將默認(rèn)搭載Linux 6.8內(nèi)核
    的頭像 發(fā)表于 01-29 11:27 ?966次閱讀

    rk3399移植Linux內(nèi)核

    RK3399是一款由中國(guó)廠商瑞芯微推出的高性能處理器芯片,被廣泛用于嵌入式系統(tǒng)開(kāi)發(fā)。在進(jìn)行應(yīng)用程序開(kāi)發(fā)之前,我們需要將Linux內(nèi)核移植到RK3399上,以支持硬件的驅(qū)動(dòng)和功能。本文將詳細(xì)介紹如何將
    的頭像 發(fā)表于 01-08 09:56 ?981次閱讀

    開(kāi)源項(xiàng)目維護(hù)者分論壇圓滿(mǎn)舉辦

    開(kāi)源維護(hù)者——一個(gè)被嚴(yán)重誤解的群體,在一個(gè)開(kāi)源項(xiàng)目中,開(kāi)源維護(hù)者 往往擁有很高的權(quán)限,比如合并其他人的代碼,又或者是無(wú)須經(jīng)過(guò)他人review就可以提交,當(dāng)這些人的心態(tài)炸裂,就會(huì)發(fā)生諸如刪庫(kù)跑路、惡意
    的頭像 發(fā)表于 12-22 18:20 ?544次閱讀
    開(kāi)源項(xiàng)目<b class='flag-5'>維護(hù)者</b>分論壇圓滿(mǎn)舉辦

    誠(chéng)邀報(bào)名|來(lái)開(kāi)源項(xiàng)目維護(hù)者論壇,為項(xiàng)目可持續(xù)發(fā)展貢獻(xiàn)您的聲音

    2023開(kāi)放原子開(kāi)發(fā)大會(huì) . OPENATOM DEVELOPERS CONFERENCE 開(kāi)源項(xiàng)目維護(hù)者論壇 2023.12.17 開(kāi)源維護(hù)者是一個(gè)被嚴(yán)重誤解的群體。在開(kāi)源項(xiàng)目中,
    的頭像 發(fā)表于 12-14 16:05 ?309次閱讀

    獲取Linux內(nèi)核源碼的方法

    (ELF1/ELF1S開(kāi)發(fā)板及顯示屏)Linux內(nèi)核是操作系統(tǒng)中最核心的部分,它負(fù)責(zé)管理計(jì)算機(jī)硬件資源,并提供對(duì)應(yīng)用程序和其他系統(tǒng)組件的訪(fǎng)問(wèn)接口,控制著計(jì)算機(jī)的內(nèi)存、處理器、設(shè)備驅(qū)動(dòng)程序和文件系統(tǒng)等
    的頭像 發(fā)表于 12-13 09:49 ?605次閱讀
    獲取<b class='flag-5'>Linux</b><b class='flag-5'>內(nèi)核</b>源碼的方法

    Linux內(nèi)核自解壓過(guò)程分析

    uboot完成系統(tǒng)引導(dǎo)以后,執(zhí)行環(huán)境變量bootm中的命令;即,將Linux內(nèi)核調(diào)入內(nèi)存中并調(diào)用do_bootm函數(shù)啟動(dòng)內(nèi)核,跳轉(zhuǎn)至kernel的起始位置。
    的頭像 發(fā)表于 12-08 14:00 ?827次閱讀
    <b class='flag-5'>Linux</b><b class='flag-5'>內(nèi)核</b>自解壓過(guò)程分析

    Linux內(nèi)核UDP收包為什么效率低

    現(xiàn)在很多人都在詬病Linux內(nèi)核協(xié)議棧收包效率低,不管他們是真的懂還是一點(diǎn)都不懂只是聽(tīng)別人說(shuō)的,反正就是在一味地懟Linux內(nèi)核協(xié)議棧,他們的武器貌似只有DPDK。 但是,即便
    的頭像 發(fā)表于 11-13 10:38 ?429次閱讀
    <b class='flag-5'>Linux</b><b class='flag-5'>內(nèi)核</b>UDP收包為什么效率低

    如何優(yōu)化Linux內(nèi)核UDP收包效率低

    很多人都在詬病Linux內(nèi)核協(xié)議棧收包效率低,不管他們是真的懂還是一點(diǎn)都不懂只是聽(tīng)別人說(shuō)的,反正就是在一味地懟Linux內(nèi)核協(xié)議棧,他們的武器貌似只有DPDK。 但是,
    的頭像 發(fā)表于 11-10 10:51 ?535次閱讀
    如何優(yōu)化<b class='flag-5'>Linux</b><b class='flag-5'>內(nèi)核</b>UDP收包效率低