使用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 能執行的時間片段。

thread and process under Linux

      在Linux kernel 中，沒有thread的concept，有別於其它的OS -XP/NT，他們的process 結構有明確的定義所屬的thread, 也較為單純，有人說是lightweight process.

     但在Linux kernel裡，thread 就是標準的process ，差別是, 它與其它稱為 "同一個process 下的threads"，共享address、file open 等resource.

     另一個要注意的名調是kernel thread, 這個thread 僅執行在kernel space, 所以他task結構中的mm是null，也就是說他沒有address space.

Activity 的四種不同工作模式

  Activity 在同一個”task" 是以堆疊的方式排放在一起，一般來若沒特別指定”模式”的話，新的Activity 會疊在前一個的上面，當最上面的Activity call finish() or 按下back key 時，該Activity 會被Destroy 掉，疊在下面的那一個會被ReStart.

      其模式可以被分為四種，Standard( 沒特別指定）、Single top 、Single task and Single instance.

       多個相同的Activity實体:

       1. Standard mode : 

                新產生的會疊在最上頭, 最上面舊OnPause -> 新onCreate -> 新onStart -> 新onRescume－＞舊OnStop 。

　　2. Single top mode:   

                若設定Single top mode 的那個Activity 不在最top 的堆疊，那start 該個Activity 時，結果與Standard mode 相同。

                若該Activity 在top ，當Start 該Activity時，會在看到同一個Activity OnPause , 接著同一個Activity 就會執行 OnResume。

      

    只有一個Activity的實体:

        　由於只有一個實体的產生，那重點是在它被疊在stack裡時候，如果有intent 傳來要start 該Activity ，那堆疊會有什麼樣的變化？是不是已經疊在上面的Activity 都會被清除，讓該個Activity 浮上來？

 

      1. Single Task Mode:(該Activity 只產生在該task 內一個實体，不同task 可存在另一個實体）

　　　當該Activity 被叫到的時候，在它上面疊著的其它Activity 都會被清掉。

       2. Single Instance Mode:（該Activity 產生的時候，只在產生一個新的task，該task 也僅有它這一個Activity，系統中僅這一個實体）  

　　　當該Activity 被叫到的時候，由於它是獨立的task，所以，在它上面疊著的其它Activity會保留，不會被影響到，因為它們是不同的task。但也因為這樣，所以當我們按back key一路退回去的時候，不會看到該instance 出現在退出的堆疊中。 

Monolithic kernel and Microkernel

          Linux 屬於Monolithic , 而NT / XP 之類則屬於MicroKernel, 兩者的差別比較：

         Monolithic Kernel:
              implemented entirely as a single process running in a single address space. Then kernel can invoke functions directly, as a user-space application might.

        Microkernel:
               the functionality of the kernel is broken into separated processes, usually called servers which are running in privileged execution mode. (other servers that don't need privileged execution mode are running under user space). So it's not possible for direct invoking function between servers, and instead, microkernels communicate via message passing.

The separation of the various servers prevents a failure in one server from bringing down another.

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

         至於兩者好壞，各有說法，可參考重新審視微核心法則, 其中強調Microkernel 最大的特色是" 可靠性 "，而Linux 是monolithic kernel ，但它也引用了Microkernel Modular 設計的概念，可以動態的載入不同的modules.

Linux Kernel 在任何時刻都處於三種狀況之一

        Linux Kernel 在任何時刻都處於三種狀況之一:

        1。In user space, executing user code in a process
        2。In kernel-space , in process context, executing on behalf of a specific process
        3。In kernel-space , in interrupt context, no associated with a process, handling an interrupt

        就算是在系統idle 時，kernel is executing an idle process in process context. 
        (from Linux.Kernel.Development.3rd.Edition -Robert Love)