使用repo sync 作為同步方式的git code database

       我們使用同一台電腦的兩個不同 folder來作為code_server 及code_client，以下將分別說明在code_server 如何建置，在code_client 如果同步。

  

     Code_Server 端:

      1。建立一個.repo 的目錄

      2。在.repo 的目錄下，建立一個manifests的目錄

      3。在manifest目錄下產生一個default.xml 的檔，並建立一個softlink (manifest.xml)到.repo的根目錄下。

      

      4。在code_server 下，建立一個mycode1 的folder ，裡面先放入一個code1.c 的檔，並且git init 成為一個git 的codebase。

    5。在.repo下，建立一個projects 的目錄，其下建立一個softlink 名為mycode1.git ，連到mycode1下的.git folder

    

   6。修改default.xml 如下：

    

   7。到.repo/manifests 目錄下，建立git database，並且在在.repo 下建立manifest.git 的 softlink到，manifest 下的.git   

     Code_Client 端：

     1. 使用以下repo 指令，先抓下manifest.xml

     2. 接著下repo sync的指，開始同步 code

     3. 可以到code 的目錄看文件內容是否一致同步下來了 (done)

Linux boot up seq. with pid0(idle) and pid1 (init)

          參考: 分析linux内核的idle的知识，可以了解到kernel idle特色，其中補充一些了解如下 ：


PID0:


    這個就是最後idle task (cpu_idle)，它是從start_kernel開始，在一連串的初始化及folk 出pid1 (kernel_init) 及pid2(kthreadd)後，就進入cpu_idle.


    cpu_idle 會引用pm_idle，這是函數指標，在initcall 的期間，設定相應的平台對應函數，例如：late_initcall(omap2_pm_init)，過此，idle休眠與平台的關係就建立起來了。


   其中initcall 是在kernel_init thread 中，於 (pid0)fork  init前，do_basic_setup()裡引用do_initcalls()。


   initcall 裡會去執行driver 的module_init，其中platform_driver_reg的動作與start_kernel下setup_arch裡的platform_device_reg中，已註冊過的device 作名字的比對配對，然後作對上的driver module init的流程。


PID1:


  同上面提到PID1 從kernel_init 這個thread 開始，最終folk 出init 這個process。


 值得一提的是，init 最後常駐在記憶体中，它主要是將init.rc的內容，parsing 為action_list 及 service_list, 分類依序配置及執行，同時最後的loop 會去watch 那些不是oneshot 的service，一旦被kill掉時，利用SIGCHLD的通知，把它們再re-start出來。


  

Android talks to service via three IPC methods

       當我們需要一些工作是在背景同執行的時候，我們會使用到service 的物件，而當該service產生之後，下一個問題就是怎麼與該service 進行溝通。

       在Android 裡，有三種IPC 方式可以使用來與Service 作互動：（如下）

１. 當該Service 僅在同一個Application執行，可以簡單讓Service extend Binder class，在Activity onServiceConnected時候，透過Binder 取得Serivce 的instance ，而後可以直接取用public 的method，來操作該個Service.且不經過marshalling and unmarshalling的動作。

   2. 當Service 不在同個Application 下，若而該Service 執行服務的函數可以依序排隊執行時，我們可以選用Messenger 的方式來進行IPC。


3. 當Service 不在同一個Application 下，且Service 執行服務的動作需求同時並行，那就必需使用上AIDL（Android Interface Definition Language).

Linux Process 排程-3 (Processes Priority and time slice)

     所謂的Process Priority 指的是Process 能使用CPU的優先順序，以Linux 的系統為例，有兩個值影響Process Priority：

    nice value愈大，表示該process 對系統其它的processes愈"nice"，因為它使用CPU的優先權較低.

  real -time priority value ，則與nice value相反，它的值愈大，其優先權愈大。

     一般embedded system中，依功能性的不同，而存在不同優先順序的tasks。通常提供服務的task或者是time critical的task，會給予較高的優先權，以提供使用者或client task 較好的response time 及服務，相對的使用服務的task其Priority 就較低。 

     依不同的系統設計，高Priority value 的task 通常會給予較長的time slice 或是優先執行完畢(非Linux目前作法，後述) 。而當多個task 指定同一個Priority value時，可以採取round-robin的方式，讓每個相同priority value的task輪流分到一個time slice 的CPU 使用時段，repeat cycle.（假設以high priority task 優先執行畢的系統為例）

     其中指的Time slice 就是CPU 執行的duration for given process.這個值如果定義的太大，那系統執行起來就沒有concurrent 執行的感覺，也就是user interactive response會大長，感覺不好，但反之如果設的太短，那花在task context switch 的overhead就會太多，浪費了CPU整體的資源。

     在Linux CFS (Completely Fair Scheduler)的設定下，time slice 並非一個固定值，而是依據正在執行的processes 它們的nice value，來分配各個process 使用CPU的比例(proportion)，也就是會依系統的loading 及其對應的priority value 來作time slice 動態的調整。

    在CFS 排程下，一個新加入的process 是否能preempting current process，立即執行，是根據該Process 的priority 及available time slice，而Linux 較新的CFS 中，這個動作的決策，則是依據佔CPU proportion 來決定，例如，原本的系統中有三個processes A(50%)　－＞　B(30%)　－＞C(20%)－＞A，假設有個D Process 產生在B執行的期間，那如果D佔CPU proportion會高於B, 那它會稍後執行A->B->D->C-A ，反之，D可以preempting B立即執行，那會變成是A->D->B->C->A。（以上的想法的假設，後續更了解後，如果有誤，再回頭修改）



       In Linux, under the new CFS scheduler, the decision is a function of how much of a proportion of the processor the newly runnable processor has consumed. If it has consumed a smaller proportion of the processor than the currently 

executing process, it runs immediately, preempting the current process. If not, it is scheduled 

to run at a later time.

(from Linux.Kernel.Development.3rd.Edition -Robert Love)


    

Linux Process 排程-2 (I/O bound vs Processor -bound)

      一般Process 我們可以依它使用CPU的特性分為I/O-bound 及Processor-bound .

      I/O bound 指的是它用少量CPU 的時間，多數時間用來等待I/O 的input，例如Key input。

      Processor-bound 則是以使用CPU的時間為主，例如一個無窮迴圈。

      而一個系統的排程，通常會希望達到最小延遲的表現，也就要較好的user interactive response time。因此，以此為Policy 排程通常是以I/O-bound 的process 為優先。        

    

Lormann-pilot: Monolithic kernel and Microkernel

Lormann-pilot: Monolithic kernel and Microkernel: " Linux 屬於Monolithic , 而NT / XP 之類則屬於MicroKernel, 兩者的差別比較： Monolithic Ke..."

Linux Process 排程-1

       所謂的process 排程，就是指CPU 的資源作有效的安排  ("which next process" 、”when" and "how long").

       多工執行的系統有分為preemptive multitasking and cooperative multitasking. Linux 使用的是前者，preemptive multitasking. 而preemptive 簡單說就是執行中的task(Process )，可以非自願式在執行未結束的過程中，被scheduler 將其使用的CPU 的資源交給另一個優先權較高的task. 反之cooperative multitasking 則是由佔有CPU資源的程式執行到特定段落時，將CPU 資源交出時，才作重新排程，這也就是協調多工。（除了Win3.1及MAC OS 9使用cooperative multitasking 外，多數都是採用preemptive multitasking).

在preemptive multitasking  中，有個名詞叫作timeslice，指的是每個process 能執行的時間片段。