linux內核26

❶ 現在的 linux 內核和 Linux 2.6 的內核有多大區別

區別大了，現在的內核(3.0)以上增加了設備樹，虛擬文件系統的框架也改了，基本上可以理解為二者不太兼容了

❷ linux kernel 2.6.26.3後面的 .3 是什麼意思，與2.6.26有什麼區別

是更新的版本，

2.6.26-*

我當前內核版本是2.6.24-21

應該是修復 bug吧，因為2.6.26-3好像也不是2.6.26最後的穩定版，你自己下載編譯的時候看changelog不就好了

剛去官網了，穩定版本，我下載了，

❸ Linux內核有多大，不同Linux版本內核有什麼差別呢

根據版本的不同，內核大小也不同，新版本為幾百M。

1、發行版的不同，主要是對於版本的選擇，穩定性的測試，還有錯誤修正補丁都會讓每個發行版有自己特殊的內核。

2、官方內核的不同，這個區別很好說，官方的開發是基於 git 版本控制的，去看兩個 git 版本就知道了。一般是硬體支持，還有新的功能演算法，還有驅動增減，錯誤修補什麼的。

Linux的內核版本編號有點像如下的樣子：

2.6.32-642.el6.x86_64

主版本.次版本。發布版本-修改版本。

雖然編號就是如上的方式來編寫，不過依據Linux內核的發展歷程，內核版本的定義有點不太相同。

奇數、偶數版本分類：

在2.6x版本以前，托瓦斯將內核的發展方向分為兩類，並根據這兩類內核的發展分別給予不同的內核編號，那就是：

主、次版本為奇數：開發中版本。

如2.5.xx,這種內核版本主要用於測試與發展新功能，所以通常這種版本僅有內核開發工程師會使用。如果有新增的內核程序代碼，會加到這種版本當中，等到很多工程師測試沒問題後，才加入下一版本的穩定內核中；

主、次版本為偶數：穩定版本。

如2.6.xx,等到內核功能發展成熟後會加到這類版本中，主要用在一般家庭計算機以及企業版本中，重點在於提供一個用戶相對穩定的Linux操作環境平台。

至於發布版本則是在主、次版本架構不變的情況下，新增的功能累積到一定程度後新發布的內核版本。而由於Linux 的內核是使用CPL的授權，因此大家都能夠進行內核程序代碼的修改。

因此，如果有針對一個版本的內核修改過的部分程序代碼，那麼這個被修改過的新內核版本就可以加上所謂的修改版本。

Linux內核版本與Linux發行版本。

Linux內核版本與發行版本的版本並不相同，因為所謂的Linux版本指的應該是內核版本，而目前最新的內核版本應該是4.7.2(2016/08)才對，並不會有7.x的版本出現。

(3)linux內核26擴展閱讀：

Linux內核的任務：

1、從技術層面講，內核是硬體與軟體之間的一個中間層。作用是將應用層序的請求傳遞給硬體，並充當底層驅動程序，對系統中的各種設備和組件進行定址。

2、從應用程序的層面講，應用程序與硬體沒有聯系，只與內核有聯系，內核是應用程序知道的層次中的最底層。在實際工作中內核抽象了相關細節。

3、內核是一個資源管理程序。負責將可用的共享資源(CPU時間、磁碟空間、網路連接等)分配得到各個系統進程。

4、內核就像一個庫，提供了一組面向系統的命令。系統調用對於應用程序來說，就像調用普通函數一樣。

❹ 現在的 Linux 內核和 Linux 2.6 的內核有多大區別

這個問題挺大的。2.6 時代跨度非常大，從2.6.0 (2003年12月發布[36]) 到 2.6.39(2011年5月發布), 跨越了 40 個大版本。3.0(原計劃的 2.6.40, 2011年7月發布) 到 3.19（2015年2月發布）。4.0（2015年4月發布）到4.2（2015年8月底發布）。總的來說，從進入2.6之後，每個大版本跨度開發時間大概是 2 - 3 個月。2.6.x , 3.x, 4.x，數字的遞進並沒有非常根本性，非常非常非常引人注目的大變化，但每個大版本中都有一些或大或小的功能改變。主版本號只是一個數字而已。不過要直接從 2.6.x 升級 到 3.x, 乃至 4.x，隨著時間間隔增大，出問題的機率當然大很多。個人覺得 Linux 真正走入嚴肅級別的高穩定性，高可用性，高可伸縮性的工業級別內核大概是在 2003 年後吧。一是隨著互聯網的更迅速普及，更多的人使用、參與開發。二也是社區經過11年發展，已經慢慢摸索出一套很穩定的協同開發模式，一個重要的特點是 社區開始使用版本管理工具進入管理，脫離了之前純粹手工（或一些輔助的簡陋工具）處理代碼郵件的方式，大大加快了開發的速度和力度。因此，我匯總分析一下從 2.6.12 (2005年6月發布，也就是社區開始使用 git 進行管理後的第一個大版本），到 4.2 (2015年8月發布)這中間共 51個大版本，時間跨度10年的主要大模塊的一些重要的變革。

❺ linux 內核是什麼， 本人有linux基礎

Linux內核：Linux是一種開源電腦操作系統內核。它是一個用C語言寫成，符合POSIX標準的類Unix操作系統。Linux最早是由芬蘭Linus Torvalds為嘗試在英特爾x86架構上提供自由的類Unix操作系統而開發的。該計劃開始於1991年，在計劃的早期有一些Minix 黑客提供了協助，而今天全球無數程序員正在為該計劃無償提供幫助。

Linux最早是由芬蘭人Linus Torvalds設計的。當時由於UNⅨ的商業化，Andrew Tannebaum教授開發了Minix操作系統以便於不受AT&T許可協議的約束，為教學科研提供一個操作系統。

(5)linux內核26擴展閱讀：

Linux將標準的GNU許可協議改稱Copyleft，以便與Copyright相對照。通用的公共許可（GPL）允許用戶銷售、拷貝和改變具有Copyleft的應用程序。當然這些程序也可以是Copyright的，但是你必須允許進一步的銷售、拷貝和對其代碼進行改變，同時也必須使他人可以免費得到修改後的源代碼。事實證明，GPL對於Linux的成功起到了極大的作用。它啟動了一個十分繁榮的商用Linux階段，還為編程人員提供了一種凝聚力，誘使大家加入這個充滿了慈善精神的Linux運動。

❻ 如Linux的內核版本為2.6.17，這幾個數字分別表示什麼

Linux內核版本有兩種：穩定版和開發版。

Linux內核版本號由3個數字組成：r.x.y。

r：目前發布的內核主版本。
x：偶數表示穩定版本；奇數表示開發中版本。
y：錯誤修補的次數。

其中第一個數字是主版本號，第二個數字是次版本號，第三個數字是修訂版本號。如果次版本號是偶數，那麼該內核就是穩定版的；若是奇數，則是開發版的。頭兩個數字合在一齊可以描述內核系列。如穩定版的2.6.0，它是2.6版內核系列。

❼ linux內核怎麼設置開機logo

修改Linux內核啟動logo
系統環境：ubuntu 10.04 +x86
$ sudoapt-get install netpbm
$pngtopnm loongson.png > loongson.pnm
說明：用來轉換的圖片必須為 png 格式，否則會有如下提示：
pngtopnm:input file not a PNG file
$pnmquant 224 loongson.pnm > loongson224.pnm
pnmcolormap: making histogram…
pnmcolormap: 5854 colors found
pnmcolormap: choosing 224 colors…
pnmremap:222 colors found in colormap
注意：此處pnmquant 必須輸出到另一個不同名的文件，否則會出現如下錯誤提示
eg:$pnmquant 224 loongson.pnm > loongson.pnm
pnmcolormap: EOF / read error reading magic number
pnmcolormap failed, rc=256
$pnmtoplainpnm loongson224.pnm > loongson224.ppm
然後用轉換好的loongson224.ppm 替換 kernel
/drivers/video/logo/logo_linux_clut224.ppm（最好先做好備份）
,然後刪除同一目
錄下的logo_linux_clut224.c 文件，重新編譯內核即可
$ cd/home/work/kenrel/linux26_3210/drivers/video/logo
$ mvlogo_linux_clut224.ppm{,-bk}
$ cp/home/loongson/Dowload/loongson224.ppm ./
$ mvloongson224.ppm logo_linux_clut224.ppm
$ rmlogo_linux_clut224.c
$ cd///
$ makemenuconfig //在內核裡面選上logo 支持
DeviceDrivers --->
[*]Graphics support --->
[*]Bootup logo --->
[*] Standard black and whiteLinux logo
[*] Standard 16-color Linuxlogo
[*] Standard 224-color Linuxlogo
$make

❽ 如何linux內核報告問題

Linux Kernel BUG:soft lockup CPU#1 stuck分析
1.線上內核bug日誌
kernel: Deltaway too big! 18428729675200069867 ts=18446743954022816244 write stamp =18014278822746377
kernel:------------[ cut here ]------------
kernel:WARNING: at kernel/trace/ring_buffer.c:1988 rb_reserve_next_event+0x2ce/0x370()(Not tainted)
kernel:Hardware name: ProLiant DL360 G7
kernel:Moles linked in: fuse ipv6 power_meter bnx2 sg microcode serio_raw iTCO_wdtiTCO_vendor_support hpilo hpwdt i7core_edac edac_core shpchp ext4 mbcache jbd2sd_mod crc_t10dif hpsa radeon ttm drm_kms_helper drm i2c_algo_bit i2c_coredm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan]
kernel: Pid:5483, comm: master Not tainted 2.6.32-220.el6.x86_64 #1
kernel: CallTrace:
kernel:[<ffffffff81069b77>] ? warn_slowpath_common+0x87/0xc0
kernel:[<ffffffff81069bca>] ? warn_slowpath_null+0x1a/0x20
kernel:[<ffffffff810ea8ae>] ? rb_reserve_next_event+0x2ce/0x370
kernel:[<ffffffff810eab02>] ? ring_buffer_lock_reserve+0xa2/0x160
kernel:[<ffffffff810ec97c>] ? trace_buffer_lock_reserve+0x2c/0x70
kernel:[<ffffffff810ecb16>] ? trace_current_buffer_lock_reserve+0x16/0x20
kernel:[<ffffffff8107ae1e>] ? ftrace_raw_event_hrtimer_cancel+0x4e/0xb0
kernel:[<ffffffff81095e7a>] ? hrtimer_try_to_cancel+0xba/0xd0
kernel:[<ffffffff8106f634>] ? do_setitimer+0xd4/0x220
kernel:[<ffffffff8106f88a>] ? alarm_setitimer+0x3a/0x60
kernel:[<ffffffff8107c27e>] ? sys_alarm+0xe/0x20
kernel:[<ffffffff8100b308>] ? tracesys+0xd9/0xde
kernel: ---[end trace 4d0a1ef2e62cb1a2 ]---
abrt-mp-oops: Reported 1 kernel oopses to Abrt
kernel: BUG: softlockup - CPU#11 stuck for 4278190091s! [qmgr:5492]
kernel:Moles linked in: fuse ipv6 power_meter bnx2 sg microcode serio_raw iTCO_wdtiTCO_vendor_support hpilo hpwdt i7core_edac edac_core shpchp ext4 mbcache jbd2sd_mod crc_t10dif hpsa radeon ttm drm_kms_helper drm i2c_algo_bit i2c_coredm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan]
kernel: CPU 11
kernel:Moles linked in: fuse ipv6 power_meter bnx2 sg microcode serio_raw iTCO_wdtiTCO_vendor_support hpilo hpwdt i7core_edac edac_core shpchp ext4 mbcache jbd2sd_mod crc_t10dif hpsa radeon ttm drm_kms_helper drm i2c_algo_bit i2c_coredm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan]
kernel:
kernel: Pid:5492, comm: qmgr Tainted: G W ---------------- 2.6.32-220.el6.x86_64 #1 HPProLiant DL360 G7
kernel: RIP:0010:[<ffffffff8106f730>] [<ffffffff8106f730>]do_setitimer+0x1d0/0x220
kernel: RSP:0018:ffff88080a661ef8 EFLAGS: 00000286
kernel: RAX:ffff88080b175a08 RBX: ffff88080a661f18 RCX: 0000000000000000
kernel: RDX:0000000000000000 RSI: 0000000000000082 RDI: ffff88080c8c4c40
kernel: RBP:ffffffff8100bc0e R08: 0000000000000000 R09: 0099d7270e01c3f1
kernel: R10:0000000000000000 R11: 0000000000000246 R12: ffffffff810ef9a3
kernel: R13:ffff88080a661e88 R14: 0000000000000000 R15: ffff88080a65a544
kernel: FS:00007f10b245f7c0(0000) GS:ffff88083c4a0000(0000) knlGS:0000000000000000
kernel: CS:0010 DS: 0000 ES: 0000 CR0: 000000008005003b
kernel: CR2:00007ff955977380 CR3: 000000100a80b000 CR4: 00000000000006e0
kernel: DR0:0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
kernel: DR3:0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
kernel:Process qmgr (pid: 5492, threadinfo ffff88080a660000, task ffff880809577500)
kernel: Stack:
kernel:00007f10b323def0 00007f10b248ead0 00007f10b26d0f78 00007f10b248ede0
kernel:<0> ffff88080a661f68 ffffffff8106f88a 0000000000000000 0000000000000000
kernel:<0> 000000000000014c 00000000000f423d 0000000000000000 0000000000000000
kernel: CallTrace:
kernel:[<ffffffff8106f88a>] ? alarm_setitimer+0x3a/0x60
kernel:[<ffffffff8107c27e>] ? sys_alarm+0xe/0x20
kernel:[<ffffffff8100b308>] ? tracesys+0xd9/0xde
kernel: Code:89 ef e8 74 66 02 00 83 3d 15 69 b5 00 00 75 37 49 8b 84 24 70 07 00 00 48 0508 08 00 00 66 ff 00 66 66 90 fb 66 0f 1f 44 00 00 <31> c0 e9 64 fe ff ff49 8b 84 24 68 07 00 00 48 c7 80 d0 00 00
kernel: CallTrace:
kernel:[<ffffffff8106f769>] ? do_setitimer+0x209/0x220
kernel:[<ffffffff8106f88a>] ? alarm_setitimer+0x3a/0x60
kernel:[<ffffffff8107c27e>] ? sys_alarm+0xe/0x20
kernel:[<ffffffff8100b308>] ? tracesys+0xd9/0xde
abrt-mp-oops: Reported 1 kernel oopses to Abrt

2.內核軟死鎖（soft lockup）bug原因分析
Soft lockup名稱解釋：所謂，soft lockup就是說，這個bug沒有讓系統徹底死機，但是若干個進程（或者kernel thread）被鎖死在了某個狀態（一般在內核區域），很多情況下這個是由於內核鎖的使用的問題。
Linux內核對於每一個cpu都有一個監控進程，在技術界這個叫做watchdog（看門狗）。通過ps –ef | grep watchdog能夠看見，進程名稱大概是watchdog/X（數字：cpu邏輯編號1/2/3/4之類的）。這個進程或者線程每一秒鍾運行一次，否則會睡眠和待機。這個進程運行會收集每一個cpu運行時使用數據的時間並且存放到屬於每個cpu自己的內核數據結構。在內核中有很多特定的中斷函數。這些中斷函數會調用soft lockup計數，他會使用當前的時間戳與特定（對應的）cpu的內核數據結構中保存的時間對比，如果發現當前的時間戳比對應cpu保存的時間大於設定的閥值，他就假設監測進程或看門狗線程在一個相當可觀的時間還沒有執。Cpu軟鎖為什麼會產生，是怎麼產生的？如果linux內核是經過精心設計安排的CPU調度訪問，那麼怎麼會產生cpu軟死鎖？那麼只能說由於用戶開發的或者第三方軟體引入，看我們伺服器內核panic的原因就是qmgr進程引起。因為每一個無限的循環都會一直有一個cpu的執行流程（qmgr進程示一個後台郵件的消息隊列服務進程），並且擁有一定的優先順序。Cpu調度器調度一個驅動程序來運行，如果這個驅動程序有問題並且沒有被檢測到，那麼這個驅動程序將會暫用cpu的很長時間。根據前面的描述，看門狗進程會抓住（catch）這一點並且拋出一個軟死鎖（soft lockup）錯誤。軟死鎖會掛起cpu使你的系統不可用。
如果是用戶空間的進程或線程引起的問題backtrace是不會有內容的，如果內核線程那麼在soft lockup消息中會顯示出backtrace信息。
3.根據linux內核源碼分析錯誤
根據我們第一部分內核拋出的錯誤信息和call trace（linux內核的跟蹤子系統）來分析產生的具體原因。
首先根據我們的centos版本安裝相應的linux內核源碼，具體步驟如下：
（1）下載源碼的rpm包kernel-2.6.32-220.17.1.el6.src.rpm
（2）安裝相應的依賴庫，命令：yuminstall rpm-build redhat-rpm-config asciidoc newt-devel
（3）安裝源碼包：rpm -ikernel-2.6.32-220.17.1.el6.src.rpm
（4）進入建立源碼的目錄：cd~/rpmbuild/SPECS
（5）建立生成源碼目錄：rpmbuild-bp --target=`uname -m` kernel.spec

下面開始真正的根據內核bug日誌分析源碼：
（1）第一階段內核錯誤日誌分析（時間在Dec 4 14:03:34這個階段的日誌輸出代碼分析，其實這部分代碼不會導致cpu軟死鎖，主要是第二階段錯誤日誌顯示導致cpu軟死鎖）
我們首先通過日誌定位到相關源代碼：看下面日誌：Dec 4 14:03:34 BP-YZH-1-xxxx kernel: WARNING: atkernel/trace/ring_buffer.c:1988 rb_reserve_next_event+0x2ce/0x370() (Not tainted)
根據日誌內容我們可以很容易的定位到kernel/trace/ring_buffer.c這個文件的1988行代碼如下：WARN_ON(1)。
先簡單解釋一下WARN_ON的作用：WARN_ON只是列印出當前棧信息，不會panic。所以會看到後面有一大堆的棧信息。這個宏定義如下：
#ifndef WARN_ON
#defineWARN_ON(condition) ({ \
int __ret_warn_on = !!(condition); \
if (unlikely(__ret_warn_on)) \
__WARN(); \
unlikely(__ret_warn_on); \
})
#endif
這個宏很簡單保證傳遞進來的條件值為0或者1（兩次邏輯非操作的結果），然後使用分支預測技術（保證執行概率大的分支緊鄰上面的指令）判斷是否需要調用__WARN()宏定義。如果滿足條件執行了__WARN()宏定義也接著執行一條空指令;。上面調用WARN_ON宏是傳遞的1，所以會執行__WARN()。下面繼續看一下__WARN()宏定義如下：
#define __WARN() warn_slowpath_null(__FILE__,__LINE__)
從接下來的call trace信息中我們也確實發現調用了warn_slowpath_null這個函數。通過在linux內核源代碼中搜索這個函數的實現，發現在panic.c（內核恐慌時的相關功能實現）中實現如下：
voidwarn_slowpath_null(const char *file, int line)
{
warn_slowpath_common(file, line,__builtin_return_address(0),
TAINT_WARN, NULL);
}
EXPORT_SYMBOL(warn_slowpath_null);//都出這個符號，讓其他模塊可以使用這個函數
同樣的我們看到了warn_slowpath_common這個函數，而在call trace當中這個函數在warn_slowpath_null函數之前列印出來，再次印證了這個流程是正確的。同樣在panic.c這個文件中我發現了warn_slowpath_common這個函數的實現如下：
static voidwarn_slowpath_common(const char *file, int line, void *caller,
unsigned taint, struct slowpath_args *args)
{
const char *board;

printk(KERN_WARNING "------------[ cut here]------------\n");
printk(KERN_WARNING "WARNING: at %s:%d %pS()(%s)\n",
file, line, caller, print_tainted());
board = dmi_get_system_info(DMI_PRODUCT_NAME);//得到dmi系統信息
if (board)
printk(KERN_WARNING "Hardware name:%s\n", board);//通過我們的日誌信息可以發現我們硬體名稱是ProLiant DL360 G7

if (args)
vprintk(args->fmt, args->args);

print_moles();//列印系統模塊信息
mp_stack();//mp信息輸出（call trace開始）
print_oops_end_marker();//列印oops結束
add_taint(taint);
}
分析這個函數的實現不難發現我們的很多日誌信息從這里開始輸出，包括列印一些系統信息，就不繼續深入分析了（請看代碼注釋，裡面調用相關函數列印對應信息，通過我分析這些函數的實現和我們的日誌信息完全能夠對應，其中mp_stack是與cpu體系結構相關的，我們的伺服器應該是屬於x86體系）。這里在繼續分析一下mp_stack函數的實現，因為這個是與cpu體系結構相關的，而且這個函數直接反應出導致內核panic的相關進程。這個函數實現如下：
/*
* The architecture-independent mp_stackgenerator
*/
void mp_stack(void)
{
unsigned long stack;

printk("Pid: %d, comm: %.20s %s %s %.*s\n",
current->pid, current->comm,print_tainted(),
init_utsname()->release,
(int

❾ Linux內核版本號的意義

版本號(version number)為版本的標識號。每一個操作系統（或廣義的講，每一個軟體）都有一個版本號。版本號能使用戶了解所使用的操作系統是否為最新的版本以及它所提供的功能與設施。 每一個版本號可以分為主版本號與次版本號兩部分。

Linux內核使用三種不同的版本編號方式。

第一種方式用於1.0版本之前（包括1.0）。第一個版本是0.01，緊接著是0.02、0.03、0.10、0.11、0.12、0.95、0.96、0.97、0.98、0.99和之後的1.0。

第二種方式用於1.0之後到2.6，數字由三部分「A.B.C」，A代表主版本號，B代表次主版本號，C代表較小的末版本號。

第三種方式從2004年2.6.0版本開始，使用一種「time-based」的方式。3.0版本之前，是一種「A.B.C.D」的格式。七年裡，前兩個數字A.B即「2.6」保持不變，C隨著新版本的發布而增加,D代表一些bug修復，安全更新，添加新特性和驅動的次數。

(9)linux內核26擴展閱讀

Linux內核第二種方式只有在內核發生很大變化時（歷史上只發生過兩次，1994年的1.0，1996年的2.0），A才變化。可以通過數字B來判斷Linux是否穩定，偶數的B代表穩定版，奇數的B代表開發版。C代表一些bug修復，安全更新，新特性和驅動的次數。

以版本2.4.0為例，2代表主版本號，4代表次版本號，0代表改動較小的末版本號。在版本號中，序號的第二位為偶數的版本表明這是一個可以使用的穩定版本，如2.2.5，而序號的第二位為奇數的版本有一些新的東西加入，是個不一定很穩定的測試版本，如2.3.1。

這樣穩定版本來源於上一個測試版升級版本號，而一個穩定版本發展到完全成熟後就不再發展。

3.0版本之後是「A.B.C」格式，B隨著新版本的發布而增加，C代表一些bug修復，安全更新，新特性和驅動的次數。第三種方式中不再使用偶數代表穩定版，奇數代表開發版這樣的命名方式。舉個例子：3.7.0代表的不是開發版，而是穩定版。