怎樣向Android社區(qū)提交代碼

注：[2014-3-13] 向android提交patch的方式已經(jīng)更新，本文所敘述的方式不再完全匹配，請(qǐng)參考 
http://source./source/submit-patches.html

向開源社區(qū)貢獻(xiàn)代碼的方式很多，Android采用repo的方式。

由于在提交patch的時(shí)候，必須使用repo upload命令，所以，首先要安裝repo在自己的項(xiàng)目中。安裝repo在自己項(xiàng)目的步驟分兩步：
1-1.
$ curl http://android.git./repo > ~/bin/repo
$ chmod a+x ~/bin/repo

1-2.然后把~/bin加入到PATH環(huán)境變量中，如果不加的話，用repo就需要全路徑，比較麻煩，不管怎樣，下面這一步是可選的：

$ export PATH=~/bin:$PATH

2.安裝repo到自己的項(xiàng)目中，只有安裝到自己項(xiàng)目中后，才可以使用repo，即使是repo help也不例外。

$ repo init -u git://android.git./platform/manifest.git

題外話：使用repo比使用git更麻煩，在教育網(wǎng)中，repo platform幾乎是不能完成的任務(wù)，當(dāng)然，可以使用git proxy，不過這種方法并不好使，一個(gè)簡(jiǎn)單且方便的方法是搞一個(gè)VPS 。

Android 與Linux Kernel

Linux進(jìn)程調(diào)度中隊(duì)列的使用

Linux進(jìn)程調(diào)度中隊(duì)列的使用

Linux內(nèi)核中大量使用了隊(duì)列，這里僅列舉它在進(jìn)程調(diào)度中的幾處應(yīng)用。Linux內(nèi)核中的隊(duì)列是以雙鏈表的形式連接起來的，include/linux/list.h中定義了隊(duì)列并提供了一些接口，詳細(xì)的介紹可以參考[1]中的附錄。

Linux中的進(jìn)程有如下幾個(gè)主要狀態(tài)：

兩個(gè)額外的狀態(tài)是EXIT_ZOMBIE和EXIT_DEAD，表示進(jìn)程處于僵死狀態(tài)還是真正死亡。處于僵死狀態(tài)的進(jìn)程會(huì)等待其父進(jìn)程的收養(yǎng)（否則就會(huì)被init進(jìn)程收養(yǎng)），而真正死亡的進(jìn)程會(huì)被直接刪除。

狀態(tài)為TASK_RUNNING的進(jìn)程都會(huì)被放入運(yùn)行隊(duì)列（runqueue）中，這是通過task_struct（定義在include/linux/sched.h）中的run_list成員來鏈接的。不過，為了讓內(nèi)核每次都能選取優(yōu)先級(jí)最合適的進(jìn)程，Linux為每個(gè)優(yōu)先級(jí)構(gòu)建了一個(gè)queue。這是通過struct prio_array來實(shí)現(xiàn)的，struct prio_array的定義在kernel/sched.c，大致如下：

struct prio_array {

int nr_active;

unsigned long bitmap[BITMAP_SIZE];

struct list_head queue[MAX_PRIO];

};

queue成員就是隊(duì)列數(shù)組。每個(gè)CPU有各自的runqueue，每一個(gè)runqueue又有包含兩個(gè)prio_array，一個(gè)是活動(dòng)隊(duì)列，一個(gè)是時(shí)間片耗盡的隊(duì)列。當(dāng)運(yùn)行隊(duì)列空時(shí)，內(nèi)核便會(huì)交換兩個(gè)隊(duì)列的指針，原來的耗盡隊(duì)列就成了新的活動(dòng)隊(duì)列！這和prio_array中的bitmap是決定調(diào)度算法為O(1)的關(guān)鍵。

狀態(tài)為TASK_STOPPED，EXIT_ZOMBIE或EXIT_DEAD的進(jìn)程不會(huì)被放入專門的隊(duì)列中，它們直接通過pid或者通過父進(jìn)程的孩子隊(duì)列來訪問。

TASK_INTERRUPTIBLE和TASK_UNINTERRUPTIBLE狀態(tài)的進(jìn)程會(huì)被放入等待隊(duì)列。不同的是，每個(gè)等待事件都會(huì)有一個(gè)等待隊(duì)列，該隊(duì)列中的進(jìn)程等待同一事件的完成。（“事件”一個(gè)動(dòng)態(tài)的過程，不好通過具體的結(jié)構(gòu)來定義一個(gè)“事件”。這里等待一個(gè)事件就是查看某個(gè)條件是否為真，比如某個(gè)標(biāo)志變量是否為真。）wait_queue_head_t的定義在include/linux/wait.h中，如下：

typedef struct _ _wait_queue_head {

spinlock_t lock;

struct list_head task_list;

}wait_queue_head_t;

wait_queue_t的定義如下：

typedef struct _ _wait_queue {

unsigned int flags;

struct task_struct * task;

wait_queue_func_t func;

struct list_head task_list;

}wait_queue_t;

進(jìn)入等待狀態(tài)的接口有兩類：

prepare_to_wait*()/finish_wait()

wait_event*()

其實(shí)wait_event*()內(nèi)部也是調(diào)用prepare_to_wait*()，把它放入一個(gè)循環(huán)中。而且wait_event*()在事件完成時(shí)會(huì)自動(dòng)調(diào)用finish_wait()。決定使用哪個(gè)要看情況而定。（sleep_on*()是遺棄的接口，現(xiàn)在已經(jīng)不再使用，雖然還支持。）等待隊(duì)列中的進(jìn)程有兩種，一種是exclusive的進(jìn)程，另一種是nonexclusive的進(jìn)程。所謂exclusive是指喚醒的進(jìn)程等待的資源是互斥的，每次只喚醒一個(gè)（喚醒多個(gè)也可以，不過最后還是只有一個(gè)會(huì)被喚醒，其余的又被重新添加到等待隊(duì)列中，這樣效率會(huì)大打折扣）。一般，等待函數(shù)會(huì)把進(jìn)程設(shè)為nonexclusive和uninterruptible，帶“interruptible”的會(huì)專門指定狀態(tài)為interruptible；而帶“timeout”的會(huì)在超時(shí)后退出，因?yàn)樗鼤?huì)調(diào)用schedule_timeout()；帶“exclusive”的則會(huì)把進(jìn)程設(shè)為exclusive。

喚醒的接口雖然只有wake_up*()，但它內(nèi)部也分成好幾種。帶“interruptible”的喚醒函數(shù)只會(huì)喚醒狀態(tài)是TASK_INTERRUPTIBLE的進(jìn)程，而不帶的則會(huì)喚醒TASK_INTERRUPTIBLE和TASK_UNINTERRUPTIBLE的進(jìn)程；所有喚醒函數(shù)都會(huì)把等待同一事件的nonexclusive進(jìn)程全部喚醒，或者把其中一個(gè)exclusive的進(jìn)程喚醒；而帶“nr”的則會(huì)喚醒指定個(gè)數(shù)的exclusive的進(jìn)程，帶“all”的會(huì)把全部exclusive進(jìn)程喚醒。帶“sync”會(huì)忽略優(yōu)先級(jí)的檢查，高優(yōu)先級(jí)的進(jìn)程可能會(huì)被延遲。最后，持有自旋鎖時(shí)只能調(diào)用wait_up_locked()。

進(jìn)程管理是Linux內(nèi)核中最關(guān)鍵的部分，它的性能幾乎直接決定著內(nèi)核的好壞，其中使用的一些設(shè)計(jì)和算法非常復(fù)雜。這里僅僅是介紹了隊(duì)列在其中的使用情況，更深入的探索還有待繼續(xù)去探索。

參考資料：

1. 
   

   Linux Kernel Development, Second Edition, Robert Love, Sam Publishing.

   
   


2. 
   

   Understanding the Linux Kernel, 3rd Edition, Daniel P. Bovet, Marco Cesati, O'Reilly.

   
   


3. 
   

   The Linux Kernel Primer: A Top-Down Approach for x86 and PowerPC Architectures, Claudia Salzberg Rodriguez, Gordon Fischer, Steven Smolski, Prentice Hall PTR.

   
   

關(guān)于內(nèi)核搶占

內(nèi)核搶占
—————————————————
    與其他大部分Unix變體和其他大部分的操作系統(tǒng)不同， Linux完整地支持內(nèi)核搶占。
    在不支持內(nèi)核搶占的內(nèi)核中，內(nèi)核代碼可以一直執(zhí)行，到它完成為止。也就是說，調(diào)度程序沒有辦法在一個(gè)內(nèi)核級(jí)的任務(wù)正在執(zhí)行的時(shí)候重新調(diào)度 — 內(nèi)核中的各任務(wù)是協(xié)作方式調(diào)度的，不具備搶占性。
    在2.6版的內(nèi)核中，內(nèi)核引人了搶占能力；現(xiàn)在，只要重新調(diào)度是安全的，那么內(nèi)核就可以在任何時(shí)間搶占正在執(zhí)行的任務(wù)。
    那么，什么時(shí)候重新調(diào)度才是安全的呢?只要沒有持有鎖，內(nèi)核就可以進(jìn)行搶占。鎖是非搶占區(qū)域的標(biāo)志。由于內(nèi)核是支持SMP的，所以，如果沒有持有鎖，那么正在執(zhí)行的代碼就是可重新導(dǎo)入的，也就是可以搶占的。
    為了支持內(nèi)核搶占所作的第一處變動(dòng)就是每個(gè)進(jìn)程的thread_info引入了preempt_count(thread_info.preempt_count)計(jì)數(shù)器。該計(jì)數(shù)器初始值為0，每當(dāng)使用鎖的時(shí)候數(shù)值加1，釋放鎖的時(shí)候數(shù)值減1。當(dāng)數(shù)值為0的時(shí)候，內(nèi)核就可執(zhí)行搶占。從中斷返回內(nèi)核空間的時(shí)候，內(nèi)核會(huì)檢查need_resched和preempt_count的值。如果need_resched被設(shè)置，并且preempt_count為0的話，這說明有一個(gè)更為重要的任務(wù)需要執(zhí)行并且可以安全地?fù)屨迹藭r(shí)，調(diào)度程序就會(huì)調(diào)度(搶占當(dāng)前進(jìn)程)。如果preempt_count不為0，說明當(dāng)前任務(wù)持有鎖，所以搶占是不安全的。這時(shí)，就會(huì)像通常那樣直接從中斷返回當(dāng)前執(zhí)行進(jìn)程。如果當(dāng)前進(jìn)程所持有的所有的鎖都被釋放了。那么preempt_count就會(huì)重新為0。此時(shí)，釋放鎖的代碼會(huì)檢查need_resched是否被設(shè)置。如果是的話，就會(huì)調(diào)用調(diào)度程序。有些內(nèi)核代碼需要允許或禁止內(nèi)核搶占。
    如果內(nèi)核中的進(jìn)程被阻塞了，或它顯式地調(diào)用了schedule()，內(nèi)核搶占也會(huì)顯式地發(fā)生。這種形式的內(nèi)核代碼從來都是受支持的，因?yàn)楦緹o需額外的邏輯來保證內(nèi)核可以安全地發(fā)生被搶占。如果代碼顯式的調(diào)用了schedule()，那么它應(yīng)該清楚自己是可以安全地被搶占的。
    內(nèi)核搶占發(fā)生在:
    (1) 當(dāng)"從中斷處理程序"正在執(zhí)行，且返回內(nèi)核空間之前
    (2) 內(nèi)核代碼再一次具有可搶占性的時(shí)候
    (3) 如果內(nèi)核中的任務(wù)顯式的調(diào)用schedule()
    (4) 如果內(nèi)核中的任務(wù)阻塞(這同樣也會(huì)導(dǎo)致調(diào)用schedule())

對(duì)應(yīng)的英文：
Kernel Preemption
The Linux kernel, unlike most other Unix variants and many other operating systems, is a fully preemptive kernel. In non-preemptive kernels, kernel code runs until completion. That is, the scheduler is not capable of rescheduling a task while it is in the kernelkernel code is scheduled cooperatively, not preemptively. Kernel code runs until it finishes (returns to user-space) or explicitly blocks. In the 2.6 kernel, however, the Linux kernel became preemptive: It is now possible to preempt a task at any point, so long as the kernel is in a state in which it is safe to reschedule.
So when is it safe to reschedule? The kernel is capable of preempting a task running in the kernel so long as it does not hold a lock. That is, locks are used as markers of regions of non-preemptibility. Because the kernel is SMP-safe, if a lock is not held, the current code is reentrant and capable of being preempted.
The first change in supporting kernel preemption was the addition of a preemption counter, preempt_count, to each process's thread_info. This counter begins at zero and increments once for each lock that is acquired and decrements once for each lock that is released. When the counter is zero, the kernel is preemptible. Upon return from interrupt, if returning to kernel-space, the kernel checks the values of need_resched and preempt_count. If need_resched is set and preempt_count is zero, then a more important task is runnable and it is safe to preempt. Thus, the scheduler is invoked. If preempt_count is nonzero, a lock is held and it is unsafe to reschedule. In that case, the interrupt returns as usual to the currently executing task. When all the locks that the current task is holding are released, preempt_count returns to zero. At that time, the unlock code checks whether need_resched is set. If so, the scheduler is invoked. Enabling and disabling kernel preemption is sometimes required in kernel code and is discussed in Chapter 9.
Kernel preemption can also occur explicitly, when a task in the kernel blocks or explicitly calls schedule(). This form of kernel preemption has always been supported because no additional logic is required to ensure that the kernel is in a state that is safe to preempt. It is assumed that the code that explicitly calls schedule() knows it is safe to reschedule.
Kernel preemption can occur
When an interrupt handler exits, before returning to kernel-space
When kernel code becomes preemptible again
If a task in the kernel explicitly calls schedule()
If a task in the kernel blocks (which results in a call to schedule())

關(guān)于Makefile

fuck，xen-syms和xen原來是一個(gè)東西！

–
Li Haifeng
Laboratory of Service Computing Technology and System
Home page:http://