android內核模塊編譯

Ⅰ 如何添加iptables/netfilter模塊到安卓內核

所以要實現netfilter（iptables）就要從兩方面來著手：1）內核支持netfilter；2）用戶層的iptables配置命令。
1、編譯內核，支持netfilter
在宿主機上進入linux內核目錄，配置所需的內核模塊：cd/usr/SRC/linuxmakemenuconfig
選中如下內核選項：
Generalsetup---
[*]Sysctlsupport（在ROMFS文件系統中/proc/syS/Net/ipv4/出現ip_forward）
Networkingoptions---[*]NetworkPACketfiltering(replaceSIPchains)IP：NetfilterConfiguration---（全部選擇即可）
這樣在內核中就選擇支持了netfilter。接下來只需編譯並生成內核映像文件並燒寫到嵌入式系統即可。如果燒寫後重起成功進入Linux，則說明新的支持netfiter的內核已經正常運行。（注意，這里的內核選項只是一些支持netfilter/iptables的選項。這里假設原有內核已支持嵌入式系統的相關硬體，並能在嵌入式平台上運行）。
2、編譯生成iptables命令
iptables工具包可以免費從網上獲得。下載iptables工具包後，進入下載目錄，進行編譯生成可執行文件，編譯方法具體可以參考iptables目錄下的INSTALL文件：
cd/root/iptables
makeKERNEL_DIR=/usr/src/linux（指定內核目錄）
makeNO。SHARED_LIBS=1（靜態鏈接編譯生成可執行文件）
把生成的iptables可執行文件到ramdisk再下載到嵌入式系統中就可以運行。

Ⅱ 已經編譯好的內核怎麼修改vermagic

修改include/linux/vermagic.h裡面的VERMAGIC_STRING值即可。（默認是把不同部分組合起來，你直接用固定字元串硬寫，把-svn2067去掉）

Ⅲ Android源碼解析RPC系列(一)---Binder原理

看了幾天的Binder，決定有必要寫一篇博客，記錄一下學習成果，Binder是Android中比較綜合的一塊知識了，目前的理解只限於java層。首先Binder是幹嘛用的？不用說，跨進程通信全靠它，操作系統的不同進程之間，數據不共享，對於每個進程來說，它都天真地以為自己獨享了整個系統，完全不知道其他進程的存在，進程之間需要通信需要某種系統機制才能完成，在Android整個系統架構中，採用了大量的C/S架構的思想，所以Binder的作用就顯得非常重要了，但是這種機制為什麼是Binder呢？在Linux中的RPC方式有管道，消息隊列，共享內存等，消息隊列和管道採用存儲-轉發方式，即數據先從發送方緩存區拷貝到內核開辟的緩存區中，然後再從內核緩存區拷貝到接收方緩存區，這樣就有兩次拷貝過程。共享內存不需要拷貝，但控制復雜，難以使用。Binder是個折中的方案，只需要拷貝一次就行了。其次Binder的安全性比較好，好在哪裡，在下還不是很清楚，基於安全性和傳輸的效率考慮，選擇了Binder。Binder的英文意思是粘結劑，Binder對象是一個可以跨進程引用的對象，它的實體位於一個進程中，這個進程一般是Server端，該對象提供了一套方法用以實現對服務的請求，而它的引用卻遍布於系統的各個進程（Client端）之中，這樣Client通過Binder的引用訪問Server，所以說，Binder就像膠水一樣，把系統各個進程粘結在一起了，廢話確實有點多。

為了從而保障了系統的安全和穩定，整個系統被劃分成內核空間和用戶空間
內核空間：獨立於普通的應用程序，可以訪問受保護的內存空間，有訪問底層硬體設備的所有許可權。
用戶空間：相對與內核空間，上層運用程序所運行的空間就是用戶空間，用戶空間訪問內核空間的唯一方式就是系統調用。一個4G的虛擬地址空間，其中3G是用戶空間，剩餘的1G是內核空間。如果一個用戶空間想與另外一個用戶空間進行通信，就需要內核模塊支持，這個運行在內核空間的，負責各個用戶進程通過Binder通信的內核模塊叫做Binder驅動，雖然叫做Binder驅動，但是和硬體並沒有什麼關系，只是實現方式和設備驅動程序是一樣的，提供了一些標准文件操作。

在寫AIDL的時候，一般情況下，我們有兩個進程，一個作為Server端提供某種服務，然後另外一個進程作為Client端,連接Server端之後，就 可以使用Server裡面定義的服務。這種思想是一種典型的C/S的思想。值得注意的是Android系統中的Binder自身也是C/S的架構，也有Server端與Client端。一個大的C/S架構中，也有一個小的C/S架構。

先籠統的說一下，在整個Binder框架中，由系列組件組成，分別是Client、Server、ServiceManager和Binder驅動程序，其中Client、Server和ServiceManager運行在用戶空間，Binder驅動程序運行內核空間。運行在用戶空間中的Client、Server和ServiceManager，是在三個不同進程中的，Server進程中中定義了服務提供給Client進程使用，並且Server中有一個Binder實體，但是Server中定義的服務並不能直接被Client使用，它需要向ServiceManager注冊，然後Client要用服務的時候，直接向ServiceManager要，ServiceManager返回一個Binder的替身（引用）給Client，這樣Client就可以調用Server中的服務了。

場景 ：進程A要調用進程B裡面的一個draw方法處理圖片。

分析 ：在這種場景下，進程A作為Client端，進程B做為Server端，但是A/B不在同一個進程中，怎麼來調用B進程的draw方法呢，首先進程B作為Server端創建了Binder實體，為其取一個字元形式，可讀易記的名字，並將這個Binder連同名字以數據包的形式通過Binder驅動發送給ServiceManager，也就是向ServiceManager注冊的過程，告訴ServiceManager，我是進程B，擁有圖像處理的功能，ServiceManager從數據包中取出名字和引用以一個注冊表的形式保留了Server進程的注冊信息。為什麼是以數據包的形式呢，因為這是兩個進程，直接傳遞對象是不行滴，只能是一些描述信息。現在Client端進程A聯系ServiceManager，說現在我需要進程B中圖像處理的功能，ServiceManager從注冊表中查到了這個Binder實體，但是呢，它並不是直接把這個Binder實體直接給Client,而是給了一個Binder實體的代理，或者說是引用，Client通過Binder的引用訪問Server。分析到現在，有個關鍵的問題需要說一下，ServiceManager是一個進程，Server是另一個進程，Server向ServiceManager注冊Binder必然會涉及進程間通信。當前實現的是進程間通信卻又要用到進程間通信，這就好象蛋可以孵出雞前提卻是要找只雞來孵蛋，確實是這樣的，ServiceManager中預先有了一個自己的Binder對象（實體），就是那隻雞，然後Server有個Binder對象的引用，就是那個蛋，Server需要通過這個Binder的引用來實現Binder的注冊。雞就一隻，蛋有很多，ServiceManager進程的Binder對象（實體）僅有一個，其他進程所擁有的全部都是它的代理。同樣一個Server端Binder實體也應該只有一個，對應所有Client端全部都是它的代理。

我們再次理解一下Binder是什麼？在Binder通信模型的四個角色裡面；他們的代表都是「Binder」，一個Binder對象就代表了所有，包括了Server，Client,ServiceManager,這樣，對於Binder通信的使用者而言，不用關心實現的細節。對Server來說，Binder指的是Binder實體，或者說是本地對象，對於Client來說，Binder指的是Binder代理對象，也就是Binder的引用。對於Binder驅動而言，在Binder對象進行跨進程傳遞的時候，Binder驅動會自動完成這兩種類型的轉換。

簡單的總結一下，通過上面一大段的分析，一個Server在使用的時候需要經歷三個階段

1、定義一個AIDL文件
Game.aidl

GameManager .aidl

2、定義遠端服務Service
在遠程服務中的onBind方法，實現AIDL介面的具體方法，並且返回Binder對象

3、本地創建連接對象

以上就是一個遠端服務的一般套路，如果是在兩個進程中，就可以進程通信了，現在我們分析一下，這個通信的流程。重點是GameManager這個編譯生成的類。

從類的關系來看，首先介面GameManager 繼承 IInterface ，IInterface是一個介面，在GameManager內部有一個內部類Stub，Stub繼承了Binder，（Binder實現了IBinder），並且實現了GameManager介面，在Stub中還有一個內部類Proxy，Proxy也實現了GameManager介面，一個整體的結構是這樣的

現在的問題是，Stub是什麼？Proxy又是什麼？在上面說了在Binder通信模型的四個角色裡面；他們的代表都是「Binder」，一個Binder對象就代表了所有，包括了Server，Clinet，ServiceManager，為了兩個進程的通信，系統給予的內核支持是Binder,在抽象一點的說,Binder是系統開辟的一塊內存空間，兩個進程往這塊空間裡面讀寫數據就行了，Stub從Binder中讀數據，Proxy向Binder中寫數據,達到進程間通信的目的。首先我們分析Stub。

Stub 類繼承了Binder ，說明了Stub有了跨進程傳輸的能力，實現了GameManager介面，說明它有了根據游戲ID查詢一個游戲的能力。我們在bind一個Service之後，在onServiceConnecttion的回調裡面，就是通過asInterface方法拿到一個遠程的service的。

asInterface調用queryLocalInterface。

mDescriptor，mOwner其實是Binder的成員變數，Stub繼承了Binder，在構造函數的時候，對著兩個變數賦的值。

如果客戶端和服務端是在一個進程中，那麼其實queryLocalInterface獲取的就是Stub對象，如果不在一個進程queryLocalInterface查詢的對象肯定為null，因為不同進程有不同虛擬機，肯定查不到mOwner對象的，所以這時候其實是返回的Proxy對象了。拿到Stub對象後，通常在onServiceConnected中，就把這個對象轉換成我們多定義AIDL介面。

比如我們這里會轉換成GameManager，有了GameManager對象，就可以調用後querryGameById方法了。如果是一個進程，那直接調用的是自己的querryGameById方法，如果不是一個進程，那調用了就是代理的querryGameById方法了。

看到其中關鍵的一行是

mRemote就是一個IBinder對象，相對於Stub，Proxy 是組合關系（HAS-A），內部有一個IBinder對象mRemote，Stub是繼承關系(IS-A)，直接實現了IBinder介面。

transact是個native方法，最終還會回掉JAVA層的onTransact方法。

onTransact根據調用號（每個AIDL函數都有一個編號，在跨進程的時候，不會傳遞函數，而是傳遞編號指明調用哪個函數）調用相關函數；在這個例子裡面，調用了Binder本地對象的querryGameById方法；這個方法將結果返回給驅動，驅動喚醒掛起的Client進程裡面的線程並將結果返回。於是一次跨進程調用就完成了。

***Please accept mybest wishes for your happiness and success ! ***

Ⅳ 怎麼在Android程序里載入linux內核模塊

工具/原料

Android程序里載入linux內核模塊
方法/步驟

java層。 java.lang.Runtime's exec() methods:native層就是jni了。
可以用popen() 。
但指令知否支持就得看bionic了。
也可以嘗試system() and pipe。
普通apk不可能有root許可權，除非機器被root了，使用Runtime.exec之類的執行su -c insmod xx.kosu為root的象徵，配合superuser使用 。
在終端下使用su進入root用戶，然後insmod xx.ko這個肯定可以成功的，因為insmod在root用戶下執行的。但是Java的Runtime.exec()也好，Native層execl()也好，只能用su -c命令臨時在root用戶下執行一條指令。adb shell進入終端，普通用戶下執行su -c insmod xx.ko，會發現命令執行失敗，失敗原因就是需要注意的地方，su的-c參數只把下一個變數作為可執行的指令，因此其執行的命令是insmod而參數並沒有傳遞過去，xx.ko作為了su的參數，因此如果想執行成功我們需要使用su -c "insmod xx.ko"，將傳遞給insmod的參數和命令組合成一個參數。這樣的話在Java層和Native層執行失敗的問題也可以解決了，在Runtime.exec()中將命令格式進行格式化，比如Runtime.exec(「su -c 」 + "\"insmod xx.ko\"" )，或者在Native中執行execl("/sytem/bin/su","/sytem/bin/su","-c","insmod xx.ko", NULL)，這樣最終傳遞給shell的命令就是su -c "insmod xx.ko"了。

Ⅳ 安卓編譯內核生成的是o文件嗎，然後再打包進boot.img

.o是中間文件，.ko是內核模塊
kernel是一個可執行的bzImage，簡單來講就是由.o鏈接生成的目標文件，不是像你說的那樣n多.o
.ko可以編譯進內核，也可以不編譯進內核，作為插件的形式存在
安裝內核的意思就是把內核到啟動分區，然後安裝內核模塊，以及一些其他的東西。。
每次開機直接把內核裝載到內存裡面去不就行了嗎，這也得先安裝才行不是。

Ⅵ 如何向android添加內核驅動模塊

1，同目錄下的makefile，如
#
# Makefile for instrial I/O Magnetometer sensors
#

obj-$(CONFIG_SENSORS_AK8975) += ak8975.o
obj-$(CONFIG_SENSORS_HMC5843) += hmc5843.o

2，同目錄下的kconfig

#
# Magnetometer sensors
#
comment "Magnetometer sensors"

config SENSORS_AK8975
tristate "Asahi Kasei AK8975 3-Axis Magnetometer"
depends on I2C
help
Say yes here to build support for Asahi Kasei AK8975 3-Axis
Magnetometer.

To compile this driver as a mole, choose M here: the mole
will be called ak8975.

3，總的config（配置變數為Y）
各項目配置文件的位置不同，
coffee：kernel/arch/arm/configs/M7023Q-debug-perf_defconfig
juice:common/customer/configs
配置信息如下：
# CONFIG_CFG80211 is not set
CONFIG_EXPERIMENTAL=y
CONFIG_LOCALVERSION="$(KERNEL_LOCAL_VERSION)-perf"
CONFIG_SWAP=y
CONFIG_ZRAM=m
CONFIG_SYSVIPC=y
CONFIG_SENSORS_AK8975=y
......

查看變數是否在編譯時配置成功：
out/target/proct/m7023q/obj/KERNEL_OBJ/include/generated/Autoconf.h
查找CONFIG_SENSORS_AK8975
若在編譯時有配置成功，將找到這一行：
#define CONFIG_SENSORS_AK8975 1

4、修改板級文件：
4.0及後續項目統一在：kernel/arch/arm/mach-msm/board-qrd7627a.c
注意juice中，很多配置（如tp）寫在kernel/arch/arm/mach-msm/board-msm7627a-io.c
在代碼中增加新模塊的內容，應該有兩處，第一處設置函數和結構體，第二處實際調用，注意引用上述第3步新增的編譯開關將代碼限制起來。
這些內容大多可以拷貝其它模塊，但是名字要和driver中的相同，注意要改的地方除了名字之外，還有中斷腳和I2C腳。其中固定模塊的中斷腳大部分時候不會改變（如tp就是int：48，reset：26），除非板子的datasheet特別註明才需要改變。但是I2C腳是會隨著slaver device的改變而改變的，需要查清楚。
配置platform_data：
一般需要初始化一個xxx_platform_data結構體（這個結構體的聲明應該讓驅動文件可視，probe中才知道去讀某個platformdata.yyy），並在i2c_board_info結構體中用.platform_data指向它，然後這個i2c_board_info將在板級文件中被注冊（作為函數i2c_register_board_info()的參數）。而這個.platform_data很有可能在驅動的probe函數中調用到，例如：
static struct msg2133_ts_platform_data msg2133_platformdata= {
.irq = 0,
.reset = GPIO_TP_RESET,
};

static struct i2c_board_info i2c_info_msg2133_dpt = {
I2C_BOARD_INFO("msg2133", 0x27),
.platform_data = &msg2133_platformdata,
};
i2c_info_msg2133_dpt.platform_data->irq = gpio_to_irq(GPIO_TP_INT);//結構體初始化的時候只能以常量賦值，因為此處需要做GPIO到irq的映射，所以要在此處賦值。
i2c_register_board_info(MSM_GSBI1_QUP_I2C_BUS_ID, &i2c_info_msg2133_dpt, 1);
在驅動的probe中：pdata =client->dev.platform_data;
...... = pdata.yyy; ......//(msg2133_ts_platform_data在該文件中可見)