Keep Learning Everyday: 11月 2014

2014年11月25日星期二

[轉] kernel build system探索

vmlinux是如何煉成的-- kernel makefile

引子

kernel的makefile包含的內容還真是多，我就是想看看要是我自己添加一個目錄編譯到內核裡，要怎麼做。

就是這麼個不起眼的實驗，引發了一堆的故事。

最簡單的例子

添加一個目錄，叫test, 添加了test.c 和 Makefile。

文件內容很簡單，如下。

cat Makefile

#
# Makefile for the linux kernel makefile experiment.
#

obj-y := test.o

cat test.c

#include <linux/export.h>

int test_global = 0;

然後在主 Makefile中添加

-core-y += kernel/ mm/ fs/ ipc/ security/ crypto/ block/
+core-y += kernel/ mm/ fs/ ipc/ security/ crypto/ block/ test/

最後 make test

make[1]: Nothing to be done for `all'.
HOSTCC arch/x86/tools/relocs
CHK include/linux/version.h
CHK include/generated/utsrelease.h
CC kernel/bounds.s
GEN include/generated/bounds.h
CC arch/x86/kernel/asm-offsets.s
GEN     include/generated/asm-offsets.h
CALL    scripts/checksyscalls.sh
CC      test/test.o
LD      test/built-in.o

恩，不錯，可以了。

vmlinux是如何煉成的-- kernel makefile

人總是不知足的，我又開始好奇，這個build的過程究竟是怎麼個回事。

好吧，我們知道make後，最終的結果叫vmlinux，那我們就找找這個神奇的東西是怎麼

產生的吧。

vmlinux-deps := $(KBUILD_LDS) $(KBUILD_VMLINUX_INIT) $(KBUILD_VMLINUX_MAIN)

$(sort $(vmlinux-deps)): $(vmlinux-dirs) ;

vmlinux: scripts/link-vmlinux.sh $(vmlinux-deps) FORCE

ifdef CONFIG_HEADERS_CHECK
   $(Q)$(MAKE) -f $(srctree)/Makefile headers_check
endif
ifdef CONFIG_SAMPLES
   $(Q)$(MAKE) $(build)=samples
endif
ifdef CONFIG_BUILD_DOCSRC
   $(Q)$(MAKE) $(build)=Documentation
endif
   +$(call if_changed,link-vmlinux)

vmlinx 基於上面三個目標，而vmlinux-deps又基於 $(vmlinux-dirs)。恩，好複雜。

那來看看vmlinux-dirs都包含什麼吧。

在主Makefile中看到下面的內容。

core-y       += kernel/ mm/ fs/ ipc/ security/ crypto/ block/ test/

vmlinux-dirs   := $(patsubst %/,%,$(filter %/, $(init-y) $(init-m) \
             $(core-y) $(core-m) $(drivers-y) $(drivers-m) \
             $(net-y) $(net-m) $(libs-y) $(libs-m)))

$(vmlinux-dirs): prepare scripts
$(Q)$(MAKE) $(build)=$@

恩，我們把vmlinux-dirs的東東打印出來看看。

vmlinux-dris: init usr arch/x86 kernel mm fs ipc security crypto block test drivers sound firmware arch/x86/pci arch/x86/power arch/x86/video arch/x86/oprofile net lib arch/x86/lib

這樣，你是不是明白點了呢。這些都是kernel源代碼中子目錄。也就是kernel將要挨個的

進入每個子目錄，編譯～。

那最後這個vmlinux是怎麼生成的呢？怎麼樣將每個目錄下生成的模塊鏈接成一個vmlinux的文件的呢？

看到上面vmlinux目標中，最後一個命令：

+$(call if_changed,link-vmlinux)

哦，原來是調用了cmd_link-vmlinux。這個命令就定義在主Makefile中。

cmd_link-vmlinux = $(CONFIG_SHELL) $< $(LD) $(LDFLAGS) $(LDFLAGS_vmlinux)

打出來看看，長這樣。

/bin/bash $< ld -m elf_i386 --emit-relocs --build-id

$< 表示第一個以來目標，那麼在vmlinux目標中，第一個目標是 scripts/link-vmlinux.sh, 展開後就成為。

/bin/bash scripts/link-vmlinux.sh ld -m elf_i386 --emit-relocs --build-id

額，原來是又調用了一個腳本。。。好吧，再進去看看。發現這麼個東東

info LD vmlinux
vmlinux_link "${kallsymso}" vmlinux

vmlinux_link()

{
   local lds="${objtree}/${KBUILD_LDS}"

   if [ "${SRCARCH}" != "um" ]; then
       ${LD} ${LDFLAGS} ${LDFLAGS_vmlinux} -o ${2}                  \
           -T ${lds} ${KBUILD_VMLINUX_INIT}                     \
           --start-group ${KBUILD_VMLINUX_MAIN} --end-group ${1}
   else
       ${CC} ${CFLAGS_vmlinux} -o ${2}                              \
           -Wl,-T,${lds} ${KBUILD_VMLINUX_INIT}                 \
           -Wl,--start-group                                    \
               ${KBUILD_VMLINUX_MAIN}                      \
           -Wl,--end-group                                      \
           -lutil ${1}
       rm -f linux
   fi
}

好吧，原來是調用了這個函數。。。打出來看看吧。

ld -m elf_i386 --emit-relocs --build-id -o vmlinux -T arch/x86/kernel/head_32.o arch/x86/kernel/head32.o arch/x86/kernel/head.o init/built-in.o --start-group usr/built-in.o arch/x86/built-in.o kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o test/built-in.o lib/lib.a arch/x86/lib/lib.a lib/built-in.o arch/x86/lib/built-in.o drivers/built-in.o sound/built-in.o firmware/built-in.o arch/x86/pci/built-in.o arch/x86/power/built-in.o arch/x86/video/built-in.o net/built-in.o --end-group .tmp_kallsyms2.o

恩，原來真相是這樣的。最後把這麼多東西鏈接起來成為vmlinux。看到我們添加的test目錄了麼，它也生成了一個built-in.o，最後鏈接到了vmlinux中。

$ nm vmlinux | grep test_global

c198d284 B test_global

啊哦，還真有這個symbol！

神秘的built-in.o

在最後的鏈接過程中，我們可以看到，幾乎所有的依賴條件中，都會生成一個built-in.o的文件。那這個文件，是怎麼生成的呢？

$(vmlinux-dirs): prepare scripts
$(Q)$(MAKE) $(build)=$@

從這個規則中可以看到，vmlinux-dir目標是通過下面的make來生成的。展開一下看看。這個build在scripts/Kbuild.include中。

make -f scripts/Makefile.build obj=$@

對應到test目錄那就是

make -f scripts/Makefile.build obj=test

這麼看來，就要進到scripts/Makefile.build文件了。

PHONY := __build
__build:

__build: $(if $(KBUILD_BUILTIN),$(builtin-target) $(lib-target) $(extra-y)) \

   $(if $(KBUILD_MODULES),$(obj-m) $(modorder-target)) \
   $(subdir-ym) $(always)
   @:

__build是這個makefile的第一個目標，也是默認的目標。這裡面藏著一個builtin-target，看著很像，再搜搜。

ifneq ($(strip $(obj-y) $(obj-m) $(obj-n) $(obj-) $(subdir-m) $(lib-target)),)

builtin-target := $(obj)/built-in.o
endif

恩原來這個就是這麼多叫built-in.o的原因。但是要生成buit-in.o，必須要以上的這些變量不能全部為空。

那再來看看編譯這個built-in.o的規則是什麼

quiet_cmd_link_o_target = LD      $@
# If the list of objects to link is empty, just create an empty built-in.o
cmd_link_o_target = $(if $(strip $(obj-y)),\
              $(LD) $(ld_flags) -r -o $@ $(filter $(obj-y), $^) \
              $(cmd_secanalysis),\
              rm -f $@; $(AR) rcs$(KBUILD_ARFLAGS) $@)

$(builtin-target): $(obj-y) FORCE
   $(call if_changed,link_o_target)

targets += $(builtin-target)

恩，基本明白了，就是當obj-y的內容不為空，那麼就用ld來鏈接成一個built-in.o。

但是我試了一下，如果沒有obj-y那麼，也會生成一個built-in.o，但是用的是別的命令。

如在i386下，用的是

rm -f test/built-in.o; ar rcsD test/built-in.o

不知道這個是什麼高級玩意。

好了，到此為止，基本上一個最上層的框架有了一個概念。那就先休息一下～

一切盡在掌握 -- kconfig 配置系統

kconfig是個強大的工具，如果說makefile制定了完美的編譯依賴關系，那麼kconfig制定了完美的模塊的依賴關係。

源頭

在根目錄下有個Kconfig文件，這就是一切故事的起源。

整個文件就沒幾行，打出來看一眼。

# For a description of the syntax of this configuration file,
# see Documentation/kbuild/kconfig-language.txt.
#
mainmenu "Linux/$ARCH $KERNELVERSION Kernel Configuration"

config SRCARCH
string
option env="SRCARCH"

source "arch/$SRCARCH/Kconfig"

第一行就是輸出個內核版本號。

第二行應該是配置一個環境變量？不知道，以後再來看。

第三行很重要，這個是包含了一個arch目錄下的Kconfig文件。

當你打開這個文件的時候，你就發現這是一切的開始。

我們運行make menuconfig, 你可以看到，這個文件就是make menuconfig中顯示的東西。

一切都變得明朗起來，你是否有種太極生兩儀，兩儀生四象，四象生八卦的神奇感覺

剪不斷，理還亂

kernel中這麼多的模塊之間的依賴關係，簡直就是剪不斷，理還亂。

幸好在Kconfig文件中，我們可以找到一點蛛絲馬跡。

依賴 depends on

這個關鍵字表示了在某些配置選中後，本配置項才會顯示。

在 driver/pci/Kconfig文件中有，

config PCI_MSI
   bool "Message Signaled Interrupts (MSI and MSI-X)"
   depends on PCI
   depends on ARCH_SUPPORTS_MSI

可以發現，要配置MSI必須要先支持PCI。恩這個道理咱都懂，連PCI都沒有，哪裡來的MSI啊。

反向依賴 select

這個關鍵字表示了當本配置項選中後，其他的配置項也需要選中。

在 arch/x86/Kconfig文件中有：

config HIGHMEM64G
   bool "64GB"
   depends on !M386 && !M486
   select X86_PAE
   ---help---
      Select this if you have a 32-bit processor and more than 4
      gigabytes of physical RAM.

其實這個我也不懂，看上去就是說要支持更多的物理內存，那麼在x86的平台上，就要選中X86_PAE。

看上去是這麼回事兒。

革命尚未成功，同志仍需努力

好了，我要記錄的東西就到這裡了。突然這麼嘎然而止，估計大家一定意猶未盡。

但是事實就是這樣，基本的kconfig語法大家可以在 Document/kbuild/kconfig-language.txt中找到。

就不用我在這裡搬出來照抄了。

kernel模塊之間的關聯又怎能是我這樣的初學者所能理解，不能理解又豈能講得清楚。

這裡只是給大家一個入口，讓大家能夠進一步的在kernel的海洋中探索。話說，授之以魚不如授之以漁嘛。

要讓linux kernel更好的發揮作用，讓更多的人參與這個項目，幫助更多的人，還有很長的路要走。

革命尚未成功，同志仍需努力。

[轉] MTK6577+Android編譯之preloader

http://blog.csdn.net/loongembedded/article/details/38706537

[轉] MTK6577+Android編譯之kernel

http://blog.csdn.net/loongembedded/article/details/38778731

MTK代碼目錄結構

2014年11月19日星期三

[轉] 自己動手寫最簡單的Android驅動---LED驅動的編寫

http://blog.csdn.net/k_linux_man/article/details/7023824

2014年11月18日星期二

[轉] 研究 Dynamic Loader, #1: dlopen

http://www.jollen.org/blog/2007/02/dynamic_loader_1_dlopen.html

2014年11月17日星期一

2014年11月11日星期二

lknlfy Blog

http://www.cnblogs.com/lknlfy/

2014年11月10日星期一

[轉] 使用 /proc 文件系統來訪問 Linux 內核的內容

http://www.ibm.com/developerworks/cn/linux/l-proc.html

[轉] android 編譯C程序在android下可執行

Android編譯環境本身比較複雜，且不像普通的編譯環境：只有頂層目錄下才有Makefile文件，而其他的每個component都使用統一標準Android.mk. Android.mk文件本身是比較簡單的，不過它並不是我們熟悉的Makefile，而是經過了Android自身編譯系統的很多處理，因此要真正理清楚其中的聯繫還比較複雜，不過這種方式的好處在於，編寫一個新的Android.mk來給Android增加一個新的Component會比較簡單。編譯Java程序可以直接採用Eclipse的集成環境來完成，這裡就不重複了。我們主要針對C/C++來說明，下面通過一個小例子來說明，如何在Android 中增加一個C程序的Hello World：
1. 在$(YOUR_ANDROID)/ development 目錄下創建hello目錄，其中$(YOUR_ANDROID)指Android源代碼所在的目錄。
- # mkdir $(YOUR_ANDROID)/development/hello
2. 在$(YOUR_ANDROID)/external/hello/目錄編寫hello.c文件，hello.c的內容當然就是經典的HelloWorld程序：
#include <stdio.h>
int main(int argc, char **argv)
{
printf("Hello World!\n");
return 0;
}

3. 在$(YOUR_ANDROID)/external/hello/目錄編寫Android.mk文件。這是Android Makefile的標準命名，不要更改。Android.mk文件的格式和內容可以參考其他已有的Android.mk文件的寫法，針對helloworld程序的Android.mk文件內容如下：
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE_TAGS := optional
LOCAL_SRC_FILES:= \
hello.c
LOCAL_MODULE := helloworld
include $(BUILD_EXECUTABLE)

Android.mk的例外一種寫法也可以

LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)

LOCAL_STATIC_LIBRARIES := libcutils libc
LOCAL_MODULE := helloworld
LOCAL_MODULE_TAGS := eng

LOCAL_FORCE_STATIC_EXECUTABLE := true
LOCAL_SRC_FILES:= \
hello.c

LOCAL_C_INCLUDES := bionic/libc/bionic

ifeq ($(HAVE_SELINUX),true)
LOCAL_CFLAGS += -DHAVE_SELINUX
LOCAL_SHARED_LIBRARIES += libselinux
LOCAL_C_INCLUDES += external/libselinux/include
endif

include $(BUILD_EXECUTABLE)

注意上面LOCAL_SRC_FILES用來指定源文件；，LOCAL_MODULE指定要編譯的模塊的名字，下一步驟編譯時就要用到；include $(BUILD_EXECUTABLE)表示要編譯成一個可執行文件，如果想編譯成動態庫則可用BUILD_SHARED_LIBRARY，這些可以在$(YOUR_ANDROID)/build/core/config.mk查到。
4. 回到Android源代碼頂層目錄進行編譯：
# cd $(YOUR_ANDROID) && make helloworld
注意make helloworld中的目標名helloworld就是上面Android.mk文件中由LOCAL_MODULE指定的模塊名。編譯結果如下：
target thumb C: helloworld <= development/hello/hello.c
target Executable: helloworld (out/target/product/generic/obj/EXECUTABLES/helloworld_intermediates/LINKED/helloworld)
target Non-prelinked: helloworld (out/target/product/generic/symbols/system/bin/helloworld)
target Strip: helloworld (out/target/product/generic/obj/EXECUTABLES/helloworld_intermediates/helloworld)
Install: out/target/product/generic/system/bin/helloworld

5．如上面的編譯結果所示，編譯後的可執行文件存放在out/target/product/generic/system/bin/helloworld目錄
啟動Android模擬器，用如下命令將文件push到Android模擬器上：
注意: 要把SDK目錄裡的tools目錄放到PATH環境變量中.
adb shell mkdir /dev/sample
adb push hello /dev/sample/hello
adb shell chmod 777 /dev/sample/hello
先創建 /dev/sample目錄，再將編譯好的hello上傳上去，最後將hello改成可執行的。
再進入命令行模式，進入Android的shell環境：
adb shell
#cd /dev/sample
#./hello

2014年11月6日星期四

[轉] 淺析Linux等待隊列

在Linux驅動程序中，可以使用等待隊列（wait queue）來實現阻塞進程的喚醒。等待很早就作為一個基本的功能單位出現在Linux內核中，它以隊列為基礎數據結構，與進程調度機制緊密結合，能夠用於實現內核中的異步事件通知機制。

我們從它的使用範例著手，看看等待隊列是如何實現異步信號功能的。以下代碼節選自kernel/printk.c。

DECLARE_WAIT_QUEUE_HEAD(log_wait); // 初始化等待隊列頭log_wait

static DEFINE_SPINLOCK(logbuf_lock); // 定義自旋鎖logbuf_lock

int do_syslog(int type, char __user *buf, int len)

{

... ... ...

err = wait_event_interruptible(log_wait, (log_start - log_end)); // 等待

// 我們先來看看linux/wait.h中定義的wait_event_interruptible()的原型

#define wait_event_interruptible(wq, condition)

({

int __ret = 0;

if ( (!condition) )

__wait_event_interruptible(wq, condition, __ret);

__ret;

})

// wait_event_interruptible()將等待隊列加入第一個參數wq為等待隊列頭的等待隊列鏈表中，

// 當condition滿足時，wait_event_interruptible()會立即返回，否則，阻塞等待condition滿足。

// 與之類似的還有wait_event()，不同點在於wait_event_interruptible()可以被信號喚醒。

// __wait_event_interruptible()原型如下：

#define __wait_event_interruptible(wq, condition, __ret)

do {

DEFINE_WAIT(__wait); // 定義等待隊列__wait

for(;;) {

prepare_to_wait(&wq, &__wait, TASK_INTERRUPTIBLE);

// prepare_to_wait()的作用是：將等待隊列__wait加入以wq為等待隊列的等待隊列

// 鏈表中，並且將進程狀態設置為TASK_INTERRUPTIBLE

if (condition)

break; // 如果condition滿足則跳出

if (!signal_pending(current)) { // 如果不是被信號喚醒

ret = schedule_timeout(ret);

if (!ret)

break;

continue;

}

ret = - ERESTARTSYS;

break;

schedule(); // 放棄CPU，調度其它進程執行

}

finish_wait(&wq, &__wait);

// finish_wait()的作用是，將等待隊列__wait從等待隊列頭wq指向的等待隊列鏈表中移除，

// 並且將進程狀態設置為TASK_RUNNING

}while(0)

... ... ...

spin_lock_irq(&lock_wait); // 鎖定

... ... ...

log_start++; // log_start自加，使得(log_start - log_end)這個等待隊列的condition滿足

... ... ...

spin_unlock_irq(&lock_wait); // 解鎖

... ... ...

}

void wake_up_klogd(void)

{

... ... ...

wake_up_interruptible(&lock_wait); //喚醒等待隊列

}

void release_console_sem(void)

{

... ... ...

spin_lock_irqsave(&lock_wait); // 鎖定

wake_klogd = log_start - log_end;

... ... ...

spin_unlock_irqrestore(&lock_wait); // 解鎖

... ... ...

if (wake_klogd)

wake_up_klogd(); // 如果wake_klogd非負，則調用wake_up_klogd()來喚醒等待隊列

... ... ...

}

我們最後再總結一下等待隊列wait_event_interruptible()：

在wait_event_interruptible()中首先判斷conditon是不是已經滿足，如果是則直接返回0，否則調用__wait_event_interruptible()，並用__ret來存放返回值。__wait_event_interruptible()首先將定義並初始化一個wait_queue_t變量__wait，其中數據為當前進程狀態current（struct task_struct），並把__wait加入等待隊列。在無限循環中，__wait_event_interruptible()將本進程置為可中斷的掛起狀態，反覆檢查condition是否成立，如果成立則退出，如果不成立則繼續休眠；條件滿足後，即把本進程運行狀態置為運行態，並把__wait從等待隊列中清除，從而進程能夠調度運行。

掛起的進程並不會自動轉入運行的，因此，還需要一個喚醒動作，這個動作由wake_up_interruptible()完成，它將遍歷作為參數傳入的lock_wait等待隊列，將其中所有的元素（通常都是task_struct）置為運行態，從而可被調度。

訂閱：文章 (Atom)

Keep Learning Everyday

2014年11月25日星期二

[轉] kernel build system探索

[轉] MTK6577+Android編譯之preloader

[轉] MTK6577+Android編譯之kernel

MTK代碼目錄結構

2014年11月19日星期三

[轉] 自己動手寫最簡單的Android驅動---LED驅動的編寫

2014年11月18日星期二

[轉] 研究 Dynamic Loader, #1: dlopen

2014年11月17日星期一

The Linux Documentation Project

[轉] Dynamically Loaded (DL) Libraries

[轉] android驅動例子（LED燈控制）

2014年11月13日星期四

[轉] .NET Core is Open Source

[轉] HBTsai Blog

2014年11月11日星期二

lknlfy Blog

2014年11月10日星期一

[轉] 使用 /proc 文件系統來訪問 Linux 內核的內容

[轉] android 編譯C程序在android下可執行

2014年11月6日星期四

[轉] 淺析Linux等待隊列

關於我自己

網誌存檔

2014年11月25日 星期二

2014年11月19日 星期三

2014年11月18日 星期二

2014年11月17日 星期一

2014年11月13日 星期四

2014年11月11日 星期二

2014年11月10日 星期一

2014年11月6日 星期四

2014年11月25日星期二

2014年11月19日星期三

2014年11月18日星期二

2014年11月17日星期一

2014年11月13日星期四

2014年11月11日星期二

2014年11月10日星期一

2014年11月6日星期四