當前位置:首頁 » 安卓系統 » android源碼內核

android源碼內核

發布時間: 2023-03-27 13:22:38

『壹』 Android socket源碼解析(三)socket的connect源碼解析

上一篇文章著重的聊了socket服務端的bind,listen,accpet的邏輯。本文來著重聊聊connect都做了什麼?

如果遇到什麼問題,可以來本文 https://www.jianshu.com/p/da6089fdcfe1 下討論

當服務端一切都准備好了。客戶端就會嘗試的通過 connect 系統調用,嘗試的和服務端建立遠程連接。

首先校驗當前socket中是否有正確的目標地址。然後獲取IP地址和埠調用 connectToAddress 。

在這個方法中,能看到有一個 NetHooks 跟蹤socket的調用,也能看到 BlockGuard 跟蹤了socket的connect調用。因此可以hook這兩個地方跟蹤socket,不過很少用就是了。

核心方法是 socketConnect 方法,這個方法就是調用 IoBridge.connect 方法。同理也會調用到jni中。

能看到也是調用了 connect 系統調用。

文件:/ net / ipv4 / af_inet.c

在這個方法中做的事情如下:

注意 sk_prot 所指向的方法是, tcp_prot 中 connect 所指向的方法,也就是指 tcp_v4_connect .

文件:/ net / ipv4 / tcp_ipv4.c

本質上核心任務有三件:

想要能夠理解下文內容,先要明白什麼是路由表。

路由表分為兩大類:

每個路由器都有一個路由表(RIB)和轉發表 (fib表),路由表用於決策路由,轉發表決策轉發分組。下文會接觸到這兩種表。

這兩個表有什麼區別呢?

網上雖然給了如下的定義:

但實際上在linux 3.8.1中並沒有明確的區分。整個路由相關的邏輯都是使用了fib轉發表承擔的。

先來看看幾個和FIB轉發表相關的核心結構體:

熟悉Linux命令朋友一定就能認出這裡面大部分的欄位都可以通過route命令查找到。

命令執行結果如下:

在這route命令結果的欄位實際上都對應上了結構體中的欄位含義:

知道路由表的的內容後。再來FIB轉發表的內容。實際上從下面的源碼其實可以得知,路由表的獲取,實際上是先從fib轉發表的路由字典樹獲取到後在同感加工獲得路由表對象。

轉發表的內容就更加簡單

還記得在之前總結的ip地址的結構嗎?

需要進行一次tcp的通信,意味著需要把ip報文准備好。因此需要決定源ip地址和目標IP地址。目標ip地址在之前通過netd查詢到了,此時需要得到本地發送的源ip地址。

然而在實際情況下,往往是面對如下這么情況:公網一個對外的ip地址,而內網會被映射成多個不同內網的ip地址。而這個過程就是通過DDNS動態的在內存中進行更新。

因此 ip_route_connect 實際上就是選擇一個緩存好的,通過DDNS設置好的內網ip地址並找到作為結果返回,將會在之後發送包的時候填入這些存在結果信息。而查詢內網ip地址的過程,可以成為RTNetLink。

在Linux中有一個常用的命令 ifconfig 也可以實現類似增加一個內網ip地址的功能:

比如說為網卡eth0增加一個IPV6的地址。而這個過程實際上就是調用了devinet內核模塊設定好的添加新ip地址方式,並在回調中把該ip地址刷新到內存中。

注意 devinet 和 RTNetLink 嚴格來說不是一個存在同一個模塊。雖然都是使用 rtnl_register 注冊方法到rtnl模塊中:

文件:/ net / ipv4 / devinet.c

文件:/ net / ipv4 / route.c

實際上整個route模塊,是跟著ipv4 內核模塊一起初始化好的。能看到其中就根據不同的rtnl操作符號注冊了對應不同的方法。

整個DDNS的工作流程大體如下:

當然,在tcp三次握手執行之前,需要得到當前的源地址,那麼就需要通過rtnl進行查詢內存中分配的ip。

文件:/ include / net / route.h

這個方法核心就是 __ip_route_output_key .當目的地址或者源地址有其一為空,則會調用 __ip_route_output_key 填充ip地址。目的地址為空說明可能是在回環鏈路中通信,如果源地址為空,那個說明可能往目的地址通信需要填充本地被DDNS分配好的內網地址。

在這個方法中核心還是調用了 flowi4_init_output 進行flowi4結構體的初始化。

文件:/ include / net / flow.h

能看到這個過程把數據中的源地址,目的地址,源地址埠和目的地址埠,協議類型等數據給記錄下來,之後內網ip地址的查詢與更新就會頻繁的和這個結構體進行交互。

能看到實際上 flowi4 是一個用於承載數據的臨時結構體,包含了本次路由操作需要的數據。

執行的事務如下:

想要弄清楚ip路由表的核心邏輯,必須明白路由表的幾個核心的數據結構。當然網上搜索到的和本文很可能大為不同。本文是基於LInux 內核3.1.8.之後的設計幾乎都沿用這一套。

而內核將路由表進行大規模的重新設計,很大一部分的原因是網路環境日益龐大且復雜。需要全新的方式進行優化管理系統中的路由表。

下面是fib_table 路由表所涉及的數據結構:

依次從最外層的結構體介紹:

能看到路由表的存儲實際上通過字典樹的數據結構壓縮實現的。但是和常見的字典樹有點區別,這種特殊的字典樹稱為LC-trie 快速路由查找演算法

這一篇文章對於快速路由查找演算法的理解寫的很不錯: https://blog.csdn.net/dog250/article/details/6596046

首先理解字典樹:字典樹簡單的來說,就是把一串數據化為二進制格式,根據左0,右1的方式構成的。

如圖下所示:

這個過程用圖來展示,就是沿著字典樹路徑不斷向下讀,比如依次讀取abd節點就能得到00這個數字。依次讀取abeh就能得到010這個數字。

說到底這種方式只是存儲數據的一種方式。而使用數的好處就能很輕易的找到公共前綴,在字典樹中找到公共最大子樹,也就找到了公共前綴。

而LC-trie 則是在這之上做了壓縮優化處理,想要理解這個演算法,必須要明白在 tnode 中存在兩個十分核心的數據:

這負責什麼事情呢?下面就簡單說說整個lc-trie的演算法就能明白了。

當然先來看看方法 __ip_dev_find 是如何查找

文件:/ net / ipv4 / fib_trie.c

整個方法就是通過 tkey_extract_bits 生成tnode中對應的葉子節點所在index,從而通過 tnode_get_child_rcu 拿到tnode節點中index所對應的數組中獲取葉下一級別的tnode或者葉子結點。

其中查找index最為核心方法如上,這個過程,先通過key左移動pos個位,再向右邊移動(32 - bits)演算法找到對應index。

在這里能對路由壓縮演算法有一定的理解即可,本文重點不在這里。當從路由樹中找到了結果就返回 fib_result 結構體。

查詢的結果最為核心的就是 fib_table 路由表,存儲了真正的路由轉發信息

文件:/ net / ipv4 / route.c

這個方法做的事情很簡單,本質上就是想要找到這個路由的下一跳是哪裡?

在這裡面有一個核心的結構體名為 fib_nh_exception 。這個是指fib表中去往目的地址情況下最理想的下一跳的地址。

而這個結構體在上一個方法通過 find_exception 獲得.遍歷從 fib_result 獲取到 fib_nh 結構體中的 nh_exceptions 鏈表。從這鏈表中找到一模一樣的目的地址並返回得到的。

文件:/ net / ipv4 / tcp_output.c

『貳』 如何在Android 內核源碼樹中添加app應用

1. 不帶jni本地代碼

首先,在Android內核源碼中選擇一個目錄來存放HelloWorld應用的源碼,比如放到/packages/apps目錄下。和陪

(1) 在HelloWorld目錄下新建Android.mk文件,示例如下:

LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE_TAGS := eng
LOCAL_SRC_FILES := $(call all-subdir-java-files)
LOCAL_PACKAGE_NAME := HelloWorld
include $(BUILD_PACKAGE)

註:LOCAL_MODULE_TAGS的備選值有user,eng,tests,optional,這里使用的TAGS值為eng,因此,毀前僅當用戶指定的編譯纖棚清選項為eng時才會編譯該工程。

『叄』 android內核源代碼有多大

每個版本的源代碼不同,幾百兆到幾G不等。
Android是一種基於Linux的自由及開放源橋襪代碼敏弊激的操作系統,主要使用於移動設備,如智能手機和平板電腦,由Google公司和開放手機聯盟領導及開發。尚未有統一中文名稱,中國大陸地區較多人使用「安卓」或「安致」。Android操作系統最初由Andy Rubin開發,主卜頌要支持手機。

『肆』 如何在 Android 源碼環境下增大 Linux 內核的 kernel log 的緩存...

需要修改 Linux 內核源碼中的一個控制 log buffer size 的宏:CONFIG_LOG_BUF_SHIFT,buffer size 是 2 ^ shift,加大這個就可以。

一、配置

$ make menuconfig

General setup
(18)Kernel log buffer size (16 => 64KB,17 => 128KB)

二、源碼

kernel/printk.c

#define __LOG_BUF_LEN (1 << CONFIG_LOG_BUF_SHIFT)

static char __log_buf[__LOG_BUF_LEN];

可以看到,是已經在編譯時定死的一塊靜態空間,不能動態調整了。對於內核日誌,唯一亂瞎嫌可以調整的在:/proc/sys/kernel/printk*

三、限制

init/Kconfig

config LOG_BUF_SHIFT
int "Kernel log buffer size (16 => 64KB, 17 =>嘩手 128KB)"神宴
range 12 21
default 17
help
Select kernel log buffer size as a power of 2.
Examples:
17 => 128 KB
16 => 64 KB
15 => 32 KB
14 => 16 KB
13 => 8 KB
12 => 4 KB

可以看到 shift 最大值限制到了 21,也就是:2 M

$ echo "(2^21)/1024/1024" | bc
2

如果再要加大,只能改源碼了。

『伍』 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官網下載的android源碼裡面有linux內核kernel嗎

從源代碼樹下載下來的最新Android源代碼,是不包括內核代碼的,也就是Android源代碼工程默認不包含Linux Kernel代碼,而是使用預先編譯好的內核,也就是prebuilt/android-arm/kernel/kernel-qemu文件。

『柒』 Android 重學系列 ion驅動源碼淺析

上一篇文章,在解析初始化GraphicBuffer中,遇到一個ion驅動,對圖元進行管理。首先看看ion是怎麼使用的:

我們按照這個流程分析ion的源碼。

如果對ion使用感興趣,可以去這篇文章下面看 https://blog.csdn.net/hexiaolong2009/article/details/102596744

本文基於Android的Linux內核版本3.1.8

遇到什麼問題歡迎來本文討論 https://www.jianshu.com/p/5fe57566691f

什麼是ion?如果是音視頻,Camera的工程師會對這個驅動比較熟悉。最早的GPU和其他驅動協作申請一塊內存進行繪制是使用比較粗暴的共享內存。在Android系統中使用的是匿名內存。最早由三星實現了一個Display和Camera共享內存的問題,曾經在Linux社區掀起過一段時間。之後各路大牛不斷的改進之下,就成為了dma_buf驅動。並在 Linux-3.3 主線版本合入主線。現在已經廣泛的運用到各大多媒體開發中。

首先介紹dma_buf的2個角色,importer和exporter。importer是dma_buf驅動中的圖元消費者,exporter是dma_buf驅動中的圖元生產者。

這里借用大佬的圖片:

ion是基於dma_buf設計完成的。經過閱讀源碼,其實不少思路和Android的匿名內存有點相似。閱讀本文之前就算不知道dma_buf的設計思想也沒關系,我不會仔細到每一行,我會注重其在gralloc服務中的申請流程,看看ion是如何管理共享內存,為什麼要拋棄ashmem。

我們先來看看ion的file_operation:

只有一個open和ioctl函數。但是沒有mmap映射。因此mmap映射的時候一定其他對象在工作。

我們關注顯卡英偉達的初始化模塊。
文件:/ drivers / staging / android / ion / tegra / tegra_ion.c

mole_platform_driver實際上就是我之前經常提到過的mole_init的一個宏,多了一個register注冊到對應名字的平台中的步驟。在這裡面注冊了一個probe方法指針,probe指向的tegra_ion_probe是載入內核模塊注冊的時候調用。

先來看看對應的結構體:

再來看看對應ion內的堆結構體:

完成的事情如下幾個步驟:

我們不關注debug模式。其實整個就是我們分析了很多次的方法。把這個對象注冊miscdevice中。等到insmod就會把整個整個內核模塊從dev_t的map中關聯出來。

我們來看看這個驅動結構體:

文件:/ drivers / staging / android / ion / ion_heap.c

這里有四個不同堆會申請出來,我們主要來看看默認的ION_HEAP_TYPE_SYSTEM對應的heap流程。

其實真正象徵ion的內存堆是下面這個結構體

不管原來的那個heap,會新建3個ion_system_heap,分別order為8,4,0,大於4為大內存。意思就是這個heap中持有一個ion_page_pool 頁資源池子,裡面只有對應order的2的次冪,內存塊。其實就和夥伴系統有點相似。

還會設置flag為ION_HEAP_FLAG_DEFER_FREE,這個標志位後面會用到。

文件:/ drivers / staging / android / ion / ion_page_pool.c

在pool中分為2個鏈表一個是high_items,另一個是low_items。他們之間的區分在此時就是以2為底4的次冪為分界線。

文件:/ drivers / staging / android / ion / ion.c

因為打開了標志位ION_HEAP_FLAG_DEFER_FREE和heap存在shrink方法。因此會初始化兩個回收函數。

文件:/ drivers / staging / android / ion / ion_heap.c

此時會創建一個內核線程,調用ion_heap_deferred_free內核不斷的循環處理。不過由於這個線程設置的是SCHED_IDLE,這是最低等級的時間片輪轉搶占。和Handler那個adle一樣的處理規則,就是閑時處理。

在這個循環中,不斷的循環銷毀處理heap的free_list裡面已經沒有用的ion_buffer緩沖對象。

文件:/ drivers / staging / android / ion / ion_system_heap.c

注冊了heap的銷毀內存的方法。當系統需要銷毀頁的時候,就會調用通過register_shrinker注冊進來的函數。

文件:/ drivers / staging / android / ion / ion_page_pool.c

整個流程很簡單,其實就是遍歷循環需要銷毀的頁面數量,接著如果是8的次冪就是移除high_items中的page緩存。4和0則銷毀low_items中的page緩存。至於為什麼是2的次冪其實很簡單,為了銷毀和申請簡單。__free_pages能夠整頁的銷毀。

文件:/ drivers / staging / android / ion / ion.c

主要就是初始化ion_client各個參數,最後把ion_client插入到ion_device的clients。來看看ion_client結構體:

核心還是調用ion_alloc申請一個ion緩沖區的句柄。最後把數據拷貝會用戶空間。

這個實際上就是找到最小能承載的大小,去申請內存。如果8kb申請內存,就會拆分積分在0-4kb,4kb-16kb,16kb-128kb區間找。剛好dma也是在128kb之內才能申請。超過這個數字就禁止申請。8kb就會拆成2個4kb保存在第一個pool中。

最後所有的申請的page都添加到pages集合中。

文件:/ drivers / staging / android / ion / ion_page_pool.c

能看到此時會從 ion_page_pool沖取出對應大小區域的空閑頁返回上層,如果最早的時候沒有則會調用ion_page_pool_alloc_pages申請一個新的page。由於引用最終來自ion_page_pool中,因此之後申請之後還是在ion_page_pool中。

這里的處理就是為了避免DMA直接內存造成的緩存差異(一般的申請,默認會帶一個DMA標志位)。換句話說,是否打開cache其實就是,關閉了則使用pool的cache,打開了則不使用pool緩存,只依賴DMA的緩存。

我們可以看另一個dma的heap,它是怎麼做到dma內存的一致性.
文件: drivers / staging / android / ion / ion_cma_heap.c

能看到它為了能辦到dma緩存的一致性,使用了dma_alloc_coherent創建了一個所有強制同步的地址,也就是沒有DMA緩存的地址。

這里出現了幾個新的結構體,sg_table和scatterlist

文件:/ lib / scatterlist.c

這裡面實際上做的事情就是一件:初始化sg_table.
sg_table中有一個核心的對象scatterlist鏈表。如果pages申請的對象數量<PAGE_SIZE/sizeof(scatterlist),每一項sg_table只有一個scatterlist。但是超出這個數字就會增加一個scatterlist。

用公式來說:

換句話說,每一次生成scatterlist的鏈表就會直接盡可能占滿一頁,讓內存更好管理。

返回了sg_table。

初始化ion_handle,並且記錄對應的ion_client是當前打開文件的進程,並且設置ion_buffer到handle中。使得句柄能夠和buffer關聯起來。

每當ion_buffer需要銷毀,

『捌』 編譯Android源碼和內核源碼的區別

Android源碼編譯之後生成的是ramdisk.img、system.img和userdata.img。而內核源碼編譯完成之後生成的是ZImage。在一般情況下Android源碼是不帶有內核源碼的,但是帶有一個鏡像,這樣在編譯完Android源碼之後就可以模擬器啟動了,如果要更換系統的內核,此時將高版本的內核源碼進行編譯生成ZImage然後替換Android系統的的鏡像。這樣使用模擬器啟動之後就可以查看內核是否已經被刷新。
請注意,android源碼和kernel源碼是分開下載的

編譯android源碼
進入source目錄下,執行make 即可。
編譯完成後,可以在源碼目錄的out/target/proct/generic/目錄下看到編譯好的ramdisk.img、system.img和userdata.img了。

編譯內核源碼
新建Kernel/goldfish,在這個目錄下進行編譯

『玖』 安卓內核源碼大小

android是一個大型的軟體系統,其內核源碼包含了很多不同唯頃的組件,具體的大小取決喊山拆於安裝的版本。一般來說,Android 內核源碼的總鄭棗大小約為10GB到20GB,如果需要下載所有的源代碼更新,可能會達到50GB以上。

『拾』 android源碼中已經包括了內核為什麼還要goldfish

我也苦惱了幾天,不過剛弄到。步驟是這樣的:先進入git下面的common目錄,輸入命令:git branch -a會列出所有的分支:* android-2.6.36 remotes/origin/HEAD -> origin/android-2.6.36 remotes/origin/android-2.6.35 remotes/origin/android-2.6.36 remotes/origin/archive/android-2.6.25 remotes/origin/archive/android-2.6.27 remotes/origin/archive/android-2.6.29 remotes/origin/archive/android-2.6.32 remotes/origin/archive/android-gldfish-2.6.29 remotes/origin/archive/android-goldfish-2.6.27如上。然後再執行git checkout origin/archive/android-goldfish-2.6.27 -b goldfish命令,一會就可以了。這樣就有golfish的部分代碼了。 查看原帖>>

熱點內容
基本原理和從頭計演算法 發布:2024-05-20 04:50:32 瀏覽:28
配置情況指的是什麼 發布:2024-05-20 04:48:14 瀏覽:495
那個程序用來編譯源文件 發布:2024-05-20 04:46:45 瀏覽:549
小程序需要資料庫嗎 發布:2024-05-20 04:35:14 瀏覽:337
鏈接sqlserver 發布:2024-05-20 04:27:53 瀏覽:209
ftp文件伺服器擴容 發布:2024-05-20 04:22:21 瀏覽:646
linux心跳包 發布:2024-05-20 04:17:52 瀏覽:970
android打開資料庫文件 發布:2024-05-20 04:16:07 瀏覽:572
塑料解壓 發布:2024-05-20 03:50:09 瀏覽:76
python在伺服器端開發 發布:2024-05-20 03:31:17 瀏覽:66