linux源碼分析訓練

Ⅰ linux內核源碼剖析的介紹

《Linux內核源碼剖析》是由樊東東，莫瀾編著，機械工業出版社於2011年1月1日出版的一本書籍。本書詳細論述了Linux內核2.6.20版本中TCP/IP的實現。書中給出了大量的源代碼，通過對源代碼的詳細注釋，幫助讀者掌握TCP/IP的實現。本書根據協議棧層次，從驅動層逐步論述到傳輸層，包括驅動的實現、介面層的輸入輸出、IP層的輸入輸出以及IP選項的處理、鄰居子系統、路由、套介面及傳輸層等內容，全書基本涵蓋了網路體系架構全部的知識點。特別是TCP，包括TCP連接的建立和終止、輸入與輸出，以及擁塞控制的實現。

Ⅱ Linux 之mutex 源碼分析

 mutex相關的函數並不是linux kernel實現的，而是glibc實現的，源碼位於nptl目錄下。

http://ftp.gnu.org/pub/gnu/glibc/glibc-2.3.5.tar.gz

首先說數據結構：

typedef union

{

  struct

  {

    int __lock;

    unsigned int __count;

    int __owner;

    unsigned int __nusers;

    /* KIND must stay at this position in the structure to maintain

       binary compatibility.  */

    int __kind;

    int __spins;

  } __data;

  char __size[__SIZEOF_PTHREAD_MUTEX_T];

  long int __align;

} pthread_mutex_t;

 int __lock;  資源競爭引用計數

 int __kind; 鎖類型，init 函數中mutexattr 參數傳遞，該參數可以為NULL，一般為 PTHREAD_MUTEX_NORMAL

結構體其他元素暫時不了解，以後更新。

/*nptl/pthread_mutex_init.c*/

int

__pthread_mutex_init (mutex, mutexattr)

     pthread_mutex_t *mutex;

     const pthread_mutexattr_t *mutexattr;

{

  const struct pthread_mutexattr *imutexattr;

  assert (sizeof (pthread_mutex_t) <= __SIZEOF_PTHREAD_MUTEX_T);

  imutexattr = (const struct pthread_mutexattr *) mutexattr ?: &default_attr;

  /* Clear the whole variable.  */

  memset (mutex, '\0', __SIZEOF_PTHREAD_MUTEX_T);

  /* Copy the values from the attribute.  */

  mutex->__data.__kind = imutexattr->mutexkind & ~0x80000000;

  /* Default values: mutex not used yet.  */

  // mutex->__count = 0;        already done by memset

  // mutex->__owner = 0;        already done by memset

  // mutex->__nusers = 0;        already done by memset

  // mutex->__spins = 0;        already done by memset

  return 0;

}

init函數就比較簡單了，將mutex結構體清零，設置結構體中__kind屬性。

/*nptl/pthread_mutex_lock.c*/

int

__pthread_mutex_lock (mutex)

     pthread_mutex_t *mutex;

{

  assert (sizeof (mutex->__size) >= sizeof (mutex->__data));

  pid_t id = THREAD_GETMEM (THREAD_SELF, tid);

  switch (__builtin_expect (mutex->__data.__kind, PTHREAD_MUTEX_TIMED_NP))

    {

     …

    default:

      /* Correct code cannot set any other type.  */

    case PTHREAD_MUTEX_TIMED_NP:

    simple:

      /* Normal mutex.  */

      LLL_MUTEX_LOCK (mutex->__data.__lock);

      break;

  …

  }

  /* Record the ownership.  */

  assert (mutex->__data.__owner == 0);

  mutex->__data.__owner = id;

#ifndef NO_INCR

  ++mutex->__data.__nusers;

#endif

  return 0;

}

該函數主要是調用LLL_MUTEX_LOCK， 省略部分為根據mutex結構體__kind屬性不同值做些處理。

宏定義函數LLL_MUTEX_LOCK最終調用，將結構體mutex的__lock屬性作為參數傳遞進來

#define __lll_mutex_lock(futex)                                                \

  ((void) ({                                                                \

    int *__futex = (futex);                                                \

    if (atomic_compare_and_exchange_bool_acq (__futex, 1, 0) != 0)        \

      __lll_lock_wait (__futex);                                        \

  }))

atomic_compare_and_exchange_bool_acq (__futex, 1, 0)宏定義為：

#define atomic_compare_and_exchange_bool_acq(mem, newval, oldval) \

  ({ __typeof (mem) __gmemp = (mem);                                      \

     __typeof (*mem) __gnewval = (newval);                              \

      \

     *__gmemp == (oldval) ? (*__gmemp = __gnewval, 0) : 1; })

這個宏實現的功能是：

如果mem的值等於oldval，則把newval賦值給mem，放回0，否則不做任何處理，返回1.

由此可以看出，當mutex鎖限制的資源沒有競爭時，__lock 屬性被置為1，並返回0，不會調用__lll_lock_wait (__futex); 當存在競爭時，再次調用lock函數，該宏不做任何處理，返回1，調用__lll_lock_wait (__futex);

void

__lll_lock_wait (int *futex)

{

  do

    {

      int oldval = atomic_compare_and_exchange_val_acq (futex, 2, 1);

      if (oldval != 0)

lll_futex_wait (futex, 2);

    }

  while (atomic_compare_and_exchange_bool_acq (futex, 2, 0) != 0);

}

atomic_compare_and_exchange_val_acq (futex, 2, 1); 宏定義：

/* The only basic operation needed is compare and exchange.  */

#define atomic_compare_and_exchange_val_acq(mem, newval, oldval) \

  ({ __typeof (mem) __gmemp = (mem);                                      \

     __typeof (*mem) __gret = *__gmemp;                                      \

     __typeof (*mem) __gnewval = (newval);                              \

      \

     if (__gret == (oldval))                                              \

       *__gmemp = __gnewval;                                              \

     __gret; })

這個宏實現的功能是，當mem等於oldval時，將mem置為newval，始終返回mem原始值。

此時，futex等於1，futex將被置為2，並且返回1. 進而調用

lll_futex_wait (futex, 2);

#define lll_futex_timed_wait(ftx, val, timespec)                        \

({                                                                        \

   DO_INLINE_SYSCALL(futex, 4, (long) (ftx), FUTEX_WAIT, (int) (val),        \

     (long) (timespec));                                \

   _r10 == -1 ? -_retval : _retval;                                        \

})

該宏對於不同的平台架構會用不同的實現，採用匯編語言實現系統調用。不過確定的是調用了Linux kernel的futex系統調用。

futex在linux kernel的實現位於：kernel/futex.c

SYSCALL_DEFINE6(futex, u32 __user *, uaddr, int, op, u32, val,

struct timespec __user *, utime, u32 __user *, uaddr2,

u32, val3)

{

struct timespec ts;

ktime_t t, *tp = NULL;

u32 val2 = 0;

int cmd = op & FUTEX_CMD_MASK;

if (utime && (cmd == FUTEX_WAIT || cmd == FUTEX_LOCK_PI ||

      cmd == FUTEX_WAIT_BITSET ||

      cmd == FUTEX_WAIT_REQUEUE_PI)) {

if (_from_user(&ts, utime, sizeof(ts)) != 0)

return -EFAULT;

if (!timespec_valid(&ts))

return -EINVAL;

t = timespec_to_ktime(ts);

if (cmd == FUTEX_WAIT)

t = ktime_add_safe(ktime_get(), t);

tp = &t;

}

/*

 * requeue parameter in 'utime' if cmd == FUTEX_*_REQUEUE_*.

 * number of waiters to wake in 'utime' if cmd == FUTEX_WAKE_OP.

 */

if (cmd == FUTEX_REQUEUE || cmd == FUTEX_CMP_REQUEUE ||

    cmd == FUTEX_CMP_REQUEUE_PI || cmd == FUTEX_WAKE_OP)

val2 = (u32) (unsigned long) utime;

return do_futex(uaddr, op, val, tp, uaddr2, val2, val3);

}

futex具有六個形參，pthread_mutex_lock最終只關注了前四個。futex函數對參數進行判斷和轉化之後，直接調用do_futex。

long do_futex(u32 __user *uaddr, int op, u32 val, ktime_t *timeout,

u32 __user *uaddr2, u32 val2, u32 val3)

{

int clockrt, ret = -ENOSYS;

int cmd = op & FUTEX_CMD_MASK;

int fshared = 0;

if (!(op & FUTEX_PRIVATE_FLAG))

fshared = 1;

clockrt = op & FUTEX_CLOCK_REALTIME;

if (clockrt && cmd != FUTEX_WAIT_BITSET && cmd != FUTEX_WAIT_REQUEUE_PI)

return -ENOSYS;

switch (cmd) {

case FUTEX_WAIT:

val3 = FUTEX_BITSET_MATCH_ANY;

case FUTEX_WAIT_BITSET:

ret = futex_wait(uaddr, fshared, val, timeout, val3, clockrt);

break;

         …

default:

ret = -ENOSYS;

}

return ret;

}

省略部分為對其他cmd的處理，pthread_mutex_lock函數最終傳入的cmd參數為FUTEX_WAIT，所以在此只關注此分之，分析futex_wait函數的實現。

static int futex_wait(u32 __user *uaddr, int fshared,

      u32 val, ktime_t *abs_time, u32 bitset, int clockrt)

{

struct hrtimer_sleeper timeout, *to = NULL;

struct restart_block *restart;

struct futex_hash_bucket *hb;

struct futex_q q;

int ret;

           … … //delete parameters check and convertion

retry:

/* Prepare to wait on uaddr. */

ret = futex_wait_setup(uaddr, val, fshared, &q, &hb);

if (ret)

goto out;

/* queue_me and wait for wakeup, timeout, or a signal. */

futex_wait_queue_me(hb, &q, to);

… … //other handlers

return ret;

}

futex_wait_setup 將線程放進休眠隊列中，

futex_wait_queue_me(hb, &q, to);將本線程休眠，等待喚醒。

喚醒後，__lll_lock_wait函數中的while (atomic_compare_and_exchange_bool_acq (futex, 2, 0) != 0); 語句將被執行，由於此時futex在pthread_mutex_unlock中置為0，所以atomic_compare_and_exchange_bool_acq (futex, 2, 0)語句將futex置為2，返回0. 退出循環，訪問用戶控制項的臨界資源。

/*nptl/pthread_mutex_unlock.c*/

int

internal_function attribute_hidden

__pthread_mutex_unlock_usercnt (mutex, decr)

     pthread_mutex_t *mutex;

     int decr;

{

  switch (__builtin_expect (mutex->__data.__kind, PTHREAD_MUTEX_TIMED_NP))

    {

   … …

    default:

      /* Correct code cannot set any other type.  */

    case PTHREAD_MUTEX_TIMED_NP:

    case PTHREAD_MUTEX_ADAPTIVE_NP:

      /* Normal mutex.  Nothing special to do.  */

      break;

    }

  /* Always reset the owner field.  */

  mutex->__data.__owner = 0;

  if (decr)

    /* One less user.  */

    --mutex->__data.__nusers;

  /* Unlock.  */

  lll_mutex_unlock (mutex->__data.__lock);

  return 0;

}

省略部分是針對不同的__kind屬性值做的一些處理，最終調用 lll_mutex_unlock。

該宏函數最終的定義為：

#define __lll_mutex_unlock(futex)                        \

  ((void) ({                                                \

    int *__futex = (futex);                                \

    int __val = atomic_exchange_rel (__futex, 0);        \

\

    if (__builtin_expect (__val > 1, 0))                \

      lll_futex_wake (__futex, 1);                        \

  }))

atomic_exchange_rel (__futex, 0);宏為：

#define atomic_exchange_rel(mem, value) \

  (__sync_synchronize (), __sync_lock_test_and_set (mem, value))

實現功能為：將mem設置為value，返回原始mem值。

__builtin_expect (__val > 1, 0) 是編譯器優化語句，告訴編譯器期望值，也就是大多數情況下__val > 1 ？是0，其邏輯判斷依然為if(__val > 1)為真的話執行 lll_futex_wake。

現在分析，在資源沒有被競爭的情況下，__futex 為1，那麼返回值__val則為1，那麼 lll_futex_wake (__futex, 1);        不會被執行，不產生系統調用。 當資源產生競爭的情況時，根據對pthread_mutex_lock 函數的分析，__futex為2， __val則為2，執行 lll_futex_wake (__futex, 1); 從而喚醒等在臨界資源的線程。

lll_futex_wake (__futex, 1); 最終會調動同一個系統調用，即futex, 只是傳遞的cmd參數為FUTEX_WAKE。

在linux kernel的futex實現中，調用

static int futex_wake(u32 __user *uaddr, int fshared, int nr_wake, u32 bitset)

{

struct futex_hash_bucket *hb;

struct futex_q *this, *next;

struct plist_head *head;

union futex_key key = FUTEX_KEY_INIT;

int ret;

if (!bitset)

return -EINVAL;

ret = get_futex_key(uaddr, fshared, &key);

if (unlikely(ret != 0))

goto out;

hb = hash_futex(&key);

spin_lock(&hb->lock);

head = &hb->chain;

plist_for_each_entry_safe(this, next, head, list) {

if (match_futex (&this->key, &key)) {

if (this->pi_state || this->rt_waiter) {

ret = -EINVAL;

break;

}

/* Check if one of the bits is set in both bitsets */

if (!(this->bitset & bitset))

continue;

wake_futex(this);

if (++ret >= nr_wake)

break;

}

}

spin_unlock(&hb->lock);

put_futex_key(fshared, &key);

out:

return ret;

}

該函數遍歷在該mutex上休眠的所有線程，調用wake_futex進行喚醒，

static void wake_futex(struct futex_q *q)

{

struct task_struct *p = q->task;

/*

 * We set q->lock_ptr = NULL _before_ we wake up the task. If

 * a non futex wake up happens on another CPU then the task

 * might exit and p would dereference a non existing task

 * struct. Prevent this by holding a reference on p across the

 * wake up.

 */

get_task_struct(p);

plist_del(&q->list, &q->list.plist);

/*

 * The waiting task can free the futex_q as soon as

 * q->lock_ptr = NULL is written, without taking any locks. A

 * memory barrier is required here to prevent the following

 * store to lock_ptr from getting ahead of the plist_del.

 */

smp_wmb();

q->lock_ptr = NULL;

wake_up_state(p, TASK_NORMAL);

put_task_struct(p);

}

wake_up_state(p, TASK_NORMAL);  的實現位於kernel/sched.c中，屬於linux進程調度的技術。

Ⅲ 怎麼使用，手上有一本linux內核2.4版源代碼分析大全

一般在Linux系統中的/usr/src/linux*.*.*（*.*.*代表的是內核版本，如2.4.23）目錄下就是內核源代碼（如果沒有類似目錄，是因為還沒安裝內核代碼）。另外還可從互連網上下載。注意，不要總到去下載，最好使用它的鏡像站點下載。請在mirrors/里找一個合適的下載點，再到pub/linux/kernel/v2.6/目錄下去下載2.4.23內核。
代碼目錄結構
在閱讀源碼之前，還應知道Linux內核源碼的整體分布情況。現代的操作系統一般由進程管理、內存管理、文件系統、驅動程序和網路等組成。Linux內核源碼的各個目錄大致與此相對應，其組成如下（假設相對於Linux-2.4.23目錄）：
1.arch目錄包括了所有和體系結構相關的核心代碼。它下面的每一個子目錄都代表一種Linux支持的體系結構，例如i386就是Intel CPU及與之相兼容體系結構的子目錄。PC機一般都基於此目錄。
2.include目錄包括編譯核心所需要的大部分頭文件，例如與平台無關的頭文件在include/linux子目錄下。
3.init目錄包含核心的初始化代碼（不是系統的引導代碼），有main.c和Version.c兩個文件。這是研究核心如何工作的好起點。
4.mm目錄包含了所有的內存管理代碼。與具體硬體體系結構相關的內存管理代碼位於arch/*/mm目錄下。
5.drivers目錄中是系統中所有的設備驅動程序。它又進一步劃分成幾類設備驅動，每一種有對應的子目錄，如音效卡的驅動對應於drivers/sound。
6.ipc目錄包含了核心進程間的通信代碼。
7.moles目錄存放了已建好的、可動態載入的模塊。
8.fs目錄存放Linux支持的文件系統代碼。不同的文件系統有不同的子目錄對應，如ext3文件系統對應的就是ext3子目錄。
Kernel內核管理的核心代碼放在這里。同時與處理器結構相關代碼都放在arch/*/kernel目錄下。
9.net目錄里是核心的網路部分代碼，其每個子目錄對應於網路的一個方面。
10.lib目錄包含了核心的庫代碼，不過與處理器結構相關的庫代碼被放在arch/*/lib/目錄下。
11.scripts目錄包含用於配置核心的腳本文件。
12.documentation目錄下是一些文檔，是對每個目錄作用的具體說明。
一般在每個目錄下都有一個.depend文件和一個Makefile文件。這兩個文件都是編譯時使用的輔助文件。仔細閱讀這兩個文件對弄清各個文件之間的聯系和依託關系很有幫助。另外有的目錄下還有Readme文件，它是對該目錄下文件的一些說明，同樣有利於對內核源碼的理解。
在閱讀方法或順序上，有縱向與橫向之分。所謂縱向就是順著程序的執行順序逐步進行；所謂橫向，就是按模塊進行。它們經常結合在一起進行。對於Linux啟動的代碼可順著Linux的啟動順序一步步來閱讀；對於像內存管理部分，可以單獨拿出來進行閱讀分析。實際上這是一個反復的過程，不可能讀一遍就理解。

Ⅳ 如何分析linux源代碼下的定義的數據結構

Linux源代碼閱讀方法 Linux的源代碼是很龐大的，如果沒有一個好的方法是很難能夠有一個比較高的效率的。所以我首先要寫的就是我在閱讀linux源代碼的時候所採用的方法。希望會對大家有所幫助！ 首先，我找了幾本分析linux源代碼的書。有一本關於l...

Ⅳ 有沒有Linux內核源碼指導書籍

1.《Linux內核設計與實現》
本書重在原理。適合入門的最佳圖書。作者是為2.6內核加入了搶占的人，對調度部分非常精通，而調度是整個系統的核心，因此本書是很權威的。

2.《深入理解Linux內核》
此書比上一本多了些細節。是Linux內核黑客在推薦圖書時的首選。寫的比較簡單易懂，適合剛剛接觸LINUX內核的。
此書圖表很多，形象地給出了關鍵數據結構的定義，與《Linux內核源代碼情景分析》相比，本書內容緊湊，不會一個問題講解動輒上百頁，有提綱挈領的功用，但是深度上要遜於《Linux內核源代碼情景分析》。

3.《LINUX設備驅動程序(第3版)》
這書強調動手實踐！但它是講解「設備驅動」的，不是最核心的東西，而且有些東西沒硬體的話無法實踐，可能更適合驅動開發的程序員吧
其中關於同步與互斥、內存分配的部分，感覺很不錯。

4.《Linux內核源代碼情景分析》
好，很經典，是浙大教授毛德操寫的，可惜成書於2001年之後一直沒有更新。分上下冊。
很多是基於2.4內核講解的需要注意。如果學習的話也建議學習2.6，2.6跟2.4比發生了很多顯著改善，應該學習的。
全書內容博大精深，不是非常好懂，對細節問題描述比較清晰。但是感覺對內核的整體感覺不夠強。另外缺少網路部分的分析。覺得不是很適合初學者。

5.《Linux內核源代碼分析》
點評：面對中高級，這本書很好，對了解操作系統是一本不可多得的好書。
6. 《LINUXKERNEL技術手冊》
參考手冊，很薄，值得一看。

7.《深入Linux內核架構》
這本書針對的是比較新的內核版本2.6.24；內容比較全面，深入淺出。
如果沒有對Linux內核的初步結構的認識，那麼會看得比較吃力。建議可以一邊去翻在國內已經聞名已經久的四本Linux內核著作（《Linux內核原代碼情景分析》、《Linux內核設計與實現》、《深入理解Linux內核》、《Linux設備驅動程序》），再一邊看這本書，把這本書當作一個補充或者當作一個內核框架圖譜說明書來閱讀，收效會更好。

8.《Linux內核完全注釋》
主要描述和注釋了Linux0.11內核全部源代碼。對於初學Linux內核操作系統的人來講，該書能夠引領讀者快速入門，並且能全面了解一個簡單操作系統的工作機理。對於進一步學習現在的Linux內核具有非常大的指導作用。對於學習嵌入式應用的技術人員來講，通過《完全注釋》一書的學習也能迅速融入嵌入式應用領域。

9.《Orange S:一個操作系統的實現》
從只有二十行的引導扇區代碼出發，一步一步地向讀者呈現一個操作系統框架的完成過程。

Ⅵ 求一段Linux操作系統源代碼分析

Linux內核的配置系統由三個部分組成，分別是：
Makefile：分布在 Linux 內核源代碼中的 Makefile，定義 Linux 內核的編譯規則；
配置文件（config.in）：給用戶提供配置選擇的功能；
配置工具：包括配置命令解釋器（對配置腳本中使用的配置命令進行解釋）和配置用戶界面（提供基於字元界面、基於 Ncurses 圖形界面以及基於 Xwindows 圖形界面的用戶配置界面，各自對應於 Make config、Make menuconfig 和 make xconfig）。
這些配置工具都是使用腳本語言，如 Tcl/TK、Perl 編寫的（也包含一些用 C 編寫的代碼）。本文並不是對配置系統本身進行分析，而是介紹如何使用配置系統。所以，除非是配置系統的維護者，一般的內核開發者無須了解它們的原理，只需要知道如何編寫 Makefile 和配置文件就可以。所以，在本文中，我們只對 Makefile 和配置文件進行討論。另外，凡是涉及到與具體 CPU 體系結構相關的內容，我們都以 ARM 為例，這樣不僅可以將討論的問題明確化，而且對內容本身不產生影響。
2． Makefile
2.1 Makefile 概述
Makefile 的作用是根據配置的情況，構造出需要編譯的源文件列表，然後分別編譯，並把目標代碼鏈接到一起，最終形成 Linux 內核二進制文件。
由於 Linux 內核源代碼是按照樹形結構組織的，所以 Makefile 也被分布在目錄樹中。Linux 內核中的 Makefile 以及與 Makefile 直接相關的文件有：

Makefile：頂層 Makefile，是整個內核配置、編譯的總體控制文件。
.config：內核配置文件，包含由用戶選擇的配置選項，用來存放內核配置後的結果（如 make config）。
arch/*/Makefile：位於各種 CPU 體系目錄下的 Makefile，如 arch/arm/Makefile，是針對特定平台的 Makefile。
各個子目錄下的 Makefile：比如 drivers/Makefile，負責所在子目錄下源代碼的管理。
Rules.make：規則文件，被所有的 Makefile 使用。
用戶通過 make config 配置後，產生了 .config。頂層 Makefile 讀入 .config 中的配置選擇。頂層 Makefile 有兩個主要的任務：產生 vmlinux 文件和內核模塊（mole）。為了達到此目的，頂層 Makefile 遞歸的進入到內核的各個子目錄中，分別調用位於這些子目錄中的 Makefile。至於到底進入哪些子目錄，取決於內核的配置。在頂層 Makefile 中，有一句：include arch/$(ARCH)/Makefile，包含了特定 CPU 體系結構下的 Makefile，這個 Makefile 中包含了平台相關的信息。
位於各個子目錄下的 Makefile 同樣也根據 .config 給出的配置信息，構造出當前配置下需要的源文件列表，並在文件的最後有 include $(TOPDIR)/Rules.make。
Rules.make 文件起著非常重要的作用，它定義了所有 Makefile 共用的編譯規則。比如，如果需要將本目錄下所有的 c 程序編譯成匯編代碼，需要在 Makefile 中有以下的編譯規則：
%.s: %.c
$(CC) $(CFLAGS) -S $< -o $@

有很多子目錄下都有同樣的要求，就需要在各自的 Makefile 中包含此編譯規則，這會比較麻煩。而 Linux 內核中則把此類的編譯規則統一放置到 Rules.make 中，並在各自的 Makefile 中包含進了 Rules.make（include Rules.make），這樣就避免了在多個 Makefile 中重復同樣的規則。對於上面的例子，在 Rules.make 中對應的規則為：
%.s: %.c
$(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(CFLAGS_$(*F)) $(CFLAGS_$@) -S $< -o $@

2.2 Makefile 中的變數
頂層 Makefile 定義並向環境中輸出了許多變數，為各個子目錄下的 Makefile 傳遞一些信息。有些變數，比如 SUBDIRS，不僅在頂層 Makefile 中定義並且賦初值，而且在 arch/*/Makefile 還作了擴充。
常用的變數有以下幾類：
1） 版本信息
版本信息有：VERSION，PATCHLEVEL, SUBLEVEL, EXTRAVERSION，KERNELRELEASE。版本信息定義了當前內核的版本，比如 VERSION=2，PATCHLEVEL=4，SUBLEVEL=18，EXATAVERSION=-rmk7，它們共同構成內核的發行版本KERNELRELEASE：2.4.18-rmk7
2） CPU 體系結構：ARCH
在頂層 Makefile 的開頭，用 ARCH 定義目標 CPU 的體系結構，比如 ARCH:=arm 等。許多子目錄的 Makefile 中，要根據 ARCH 的定義選擇編譯源文件的列表。
3） 路徑信息：TOPDIR, SUBDIRS
TOPDIR 定義了 Linux 內核源代碼所在的根目錄。例如，各個子目錄下的 Makefile 通過 $(TOPDIR)/Rules.make 就可以找到 Rules.make 的位置。
SUBDIRS 定義了一個目錄列表，在編譯內核或模塊時，頂層 Makefile 就是根據 SUBDIRS 來決定進入哪些子目錄。SUBDIRS 的值取決於內核的配置，在頂層 Makefile 中 SUBDIRS 賦值為 kernel drivers mm fs net ipc lib；根據內核的配置情況，在 arch/*/Makefile 中擴充了 SUBDIRS 的值，參見4）中的例子。
4） 內核組成信息：HEAD, CORE_FILES, NETWORKS, DRIVERS, LIBS
Linux 內核文件 vmlinux 是由以下規則產生的：
vmlinux: $(CONFIGURATION) init/main.o init/version.o linuxsubdirs
$(LD) $(LINKFLAGS) $(HEAD) init/main.o init/version.o
--start-group
$(CORE_FILES)
$(DRIVERS)
$(NETWORKS)
$(LIBS)
--end-group
-o vmlinux
可以看出，vmlinux 是由 HEAD、main.o、version.o、CORE_FILES、DRIVERS、NETWORKS 和 LIBS 組成的。這些變數（如 HEAD）都是用來定義連接生成 vmlinux 的目標文件和庫文件列表。其中，HEAD在arch/*/Makefile 中定義，用來確定被最先鏈接進 vmlinux 的文件列表。比如，對於 ARM 系列的 CPU，HEAD 定義為：
HEAD := arch/arm/kernel/head-$(PROCESSOR).o
arch/arm/kernel/init_task.o
表明 head-$(PROCESSOR).o 和 init_task.o 需要最先被鏈接到 vmlinux 中。PROCESSOR 為 armv 或 armo，取決於目標 CPU。 CORE_FILES，NETWORK，DRIVERS 和 LIBS 在頂層 Makefile 中定義，並且由 arch/*/Makefile 根據需要進行擴充。 CORE_FILES 對應著內核的核心文件，有 kernel/kernel.o，mm/mm.o，fs/fs.o，ipc/ipc.o，可以看出，這些是組成內核最為重要的文件。同時，arch/arm/Makefile 對 CORE_FILES 進行了擴充：
# arch/arm/Makefile
# If we have a machine-specific directory, then include it in the build.
MACHDIR := arch/arm/mach-$(MACHINE)
ifeq ($(MACHDIR),$(wildcard $(MACHDIR)))
SUBDIRS += $(MACHDIR)
CORE_FILES := $(MACHDIR)/$(MACHINE).o $(CORE_FILES)
endif
HEAD := arch/arm/kernel/head-$(PROCESSOR).o
arch/arm/kernel/init_task.o
SUBDIRS += arch/arm/kernel arch/arm/mm arch/arm/lib arch/arm/nwfpe
CORE_FILES := arch/arm/kernel/kernel.o arch/arm/mm/mm.o $(CORE_FILES)
LIBS := arch/arm/lib/lib.a $(LIBS)

5） 編譯信息：CPP, CC, AS, LD, AR，CFLAGS，LINKFLAGS
在 Rules.make 中定義的是編譯的通用規則，具體到特定的場合，需要明確給出編譯環境，編譯環境就是在以上的變數中定義的。針對交叉編譯的要求，定義了 CROSS_COMPILE。比如：
CROSS_COMPILE = arm-linux-
CC = $(CROSS_COMPILE)gcc
LD = $(CROSS_COMPILE)ld
......
CROSS_COMPILE 定義了交叉編譯器前綴 arm-linux-，表明所有的交叉編譯工具都是以 arm-linux- 開頭的，所以在各個交叉編譯器工具之前，都加入了 $(CROSS_COMPILE)，以組成一個完整的交叉編譯工具文件名，比如 arm-linux-gcc。
CFLAGS 定義了傳遞給 C 編譯器的參數。
LINKFLAGS 是鏈接生成 vmlinux 時，由鏈接器使用的參數。LINKFLAGS 在 arm/*/Makefile 中定義，比如：
# arch/arm/Makefile
LINKFLAGS :=-p -X -T arch/arm/vmlinux.lds

6） 配置變數CONFIG_*
.config 文件中有許多的配置變數等式，用來說明用戶配置的結果。例如 CONFIG_MODULES=y 表明用戶選擇了 Linux 內核的模塊功能。
.config 被頂層 Makefile 包含後，就形成許多的配置變數，每個配置變數具有確定的值：y 表示本編譯選項對應的內核代碼被靜態編譯進 Linux 內核；m 表示本編譯選項對應的內核代碼被編譯成模塊；n 表示不選擇此編譯選項；如果根本就沒有選擇，那麼配置變數的值為空。
2.3 Rules.make 變數
前面講過，Rules.make 是編譯規則文件，所有的 Makefile 中都會包括 Rules.make。Rules.make 文件定義了許多變數，最為重要是那些編譯、鏈接列表變數。
O_OBJS，L_OBJS，OX_OBJS，LX_OBJS：本目錄下需要編譯進 Linux 內核 vmlinux 的目標文件列表，其中 OX_OBJS 和 LX_OBJS 中的 "X" 表明目標文件使用了 EXPORT_SYMBOL 輸出符號。
M_OBJS，MX_OBJS：本目錄下需要被編譯成可裝載模塊的目標文件列表。同樣，MX_OBJS 中的 "X" 表明目標文件使用了 EXPORT_SYMBOL 輸出符號。
O_TARGET，L_TARGET：每個子目錄下都有一個 O_TARGET 或 L_TARGET，Rules.make 首先從源代碼編譯生成 O_OBJS 和 OX_OBJS 中所有的目標文件，然後使用 $(LD) -r 把它們鏈接成一個 O_TARGET 或 L_TARGET。O_TARGET 以 .o 結尾，而 L_TARGET 以 .a 結尾。