GoogleTV Update Procedure

Android Device Driver Hacks : interrupt handler, tasklet, work queue, kernel thread, synchronization, transferring data between kernel & user space chunghan.yi@gmail.com, slowboot

Revision 작성자비고 0.1 이충한 최초작성 11/11/2011 0.2 이충한 11/15/2011 (Task/Scheduling) 0.3 이충한 11/16/2011 (Work Queue/Tasklet) 0.4 이충한 11/17/2011 (Timer, Sync) 0.7 이충한 11/28/2011 (Threaded IRQ, Ex drivers) 0.9 이충한 12/01/2011 (IPC) 0.91 이충한 12/06/2011 (Suspend) 0.92 이충한 12/07/2011 (IRQ update) 0.93 이충한 12/08/2011 (sync method) 1.0 이충한 12/09/2011 (format 변경 )

목차 1. Task & Scheduling & Preemption 2. Top Half, Bottom Halves and Deferring Work Interrupt Handler, Tasklet, Softirq, Work Queue, Threaded Interrupt 3. Timer 4. Synchronization 5. Communicatoin schemes between kernel and userspace read/write/ioctl & proc & UNIX signal kobjects & sysfs & uevent mmap & ashmem 6. Notifier 7. Suspend/Resume & Wakelock 8. Platform Device & Driver 9. Example Drivers bluetooth sleep mode driver SDIO driver Appendix References

0. 이문서에서다루고자하는내용 1) (hard/threaded)interrupt handler, tasklet, work queue, kernel thread, timer 2) Synchronization issue 3) Communication schemes between kernel and userspace 4) wakelock/suspend 5) Platform driver 6) Some kernel programming tips(schedulable/preemptible/interrupt-process context/sync issue ) 평이하고일반적인내용은빼고 ( 이건 device driver book 을참조하시길 ), Qualcomm Device Driver 에서자주사용되는방식위주로기술 단순코드나열보다는그림을통해분석하고자함!!! (*) 본문서는 Gingerbread 2.3.4(linux kernel 2.6.35) 를기준으로작성하였으나, 일부내용은 kernel version 과정확히일치하지않을수있음. (*) 본문서의내용은대부분 ICS 4.01(linux kernel 3.0.8) 에도적용가능함. (*) 본문서에기술되어있는 API 혹은 data structure 내용중에는오탈자가포함되어있을수있으며, 경우에따라서는의도적으로생략한부분도있으니, 정확한정보를위해서는관련헤더파일을참조해주시기바람.

0. 본문서가아래의질문에대해적절한답을주고있는가? 1) Task scheduling 과 kernel preemption 의개념이잘설명되어있는가? 2) Interrupt context 와 process context 란무엇인가? 3) Interrupt context(interrupt handler 등 ) 에서해서는안되는일이무엇인가? 4) Process context 에서주의해야할사항은무엇인가? 5) Top half 와 bottom half 의개념이잘설명되어있는가? 6) Shared IRQ 의개념이잘설명되어있는가? 7) Interrupt 를 disable 해야하는이유와방법이잘설명되어있는가? 8) Tasklet 은언제사용하는가? 9) Work queue 는언제사용하는가? 10) Kernel thread 는언제사용하는가? 11) Threaded interrupt handler 는언제사용하며, 주의할사항은무엇인가? 12) Concurrency 상황이언제이며, 이때어찌 ( 어떻게 programming) 해야하는가? 13) Kernel 과 user process 가통신하려면어찌해야하는가? 14) Platform driver 를작성하려면어찌해야하는가? 15) Timer 를사용하려면어찌해야하는가? 16) wakelock, suspend/resume 의개념이잘설명되어있는가? 17) Notifier 의개념이잘설명되어있는가?

0. Keywords Task Preemptive kernel Scheduling(run queue, wait queue, priority) Interrupt context & process context, context switching Top half, Bottom half Interrupt handler Tasklet, Work queue, Kernel Thread, Threaded Interrupt handler Concurrency, critical region(section) Synchronization, locking

1. Task & Scheduling & Preemption(1) task struct task_struct process descriptor unsigned long state; struct thread_info *thread_info struct task_struct int prio; unsigned long policy; unsigned long state; struct task_struct *parent; struct thread_info struct *thread_info list_head tasks; struct task_struct int prio; pit_t pid; unsigned long policy; unsigned long state; struct task_struct *parent; struct thread_info struct *thread_info list_head tasks; int prio; pit_t pid; unsigned long policy; struct task_struct *parent; struct list_head tasks; pit_t pid; struct thread_info struct exec_domain *exec_domain; unsigned long flags; unsigned long status Kernel stack task list (*) linux 에서의기본적인실행단위인, 프로세스를위한각종정보를담기위해, task_struct 가사용되고있음. (*) task_struct 는프로세스와관련된다양한자원정보를저장하고, 커널코드를실행하기위한스택과저수준의 flag 는 thread_info structure 에저장됨 ^^

1. Task & Scheduling & Preemption(2) - task 1) add_wait_queue 는 task 를 wait queue 에추가하고, task 의상태를 TASK_INTERRUPTIBLE 로변경시킴. 2) 이어호출되는 schedule() 함수는 task 를 runqueue 에서제거해줌. TASK_RUNNING current task_struct task_struct task_struct thread_info task_struct task_struct task_struct thread_info TASK_INTERRUPTIBLE <run queue> <wait queue> 1) Task 가기다리던 event 가발생하면, try_to_wake_up() 함수는 task 의상태를 TASK_RUNNING 으로변경시키고, activate_taks() 함수를호출하여 task 를 runqueue 에추가시킴. 2) remove_wait_queue 는 task 를 wait queue 에서제거함. (*) task 관련 queue 로는 wait queue 와 run queue 가있으며, run queue 에등록된 task 는실행되고, wait queue 에등록된 task 는특정조건이성립될때까지기다리게된다. (*) 위에서언급된특정함수는버전에따라차이가있을수있음. 단, 전체적인개념은동일함.

1. Task & Scheduling & Preemption(3) (*) task, wait queue, run queue 간의관계를다른각도에서보여주는그림으로, wake_up 함수가호출되면, 대기중이던해당 task 가 run queue 로이동하여 CPU 를할당받게된다 (Scheduler 가그역할을담당함 ). wake_up CPU current wait queue wait queue wait queue 프로세스 task_struct run queue 항목이비어있거나, wakeup event 를받을경우, run queue 로이동할수있다. 프로세스 우선순위별로 Queue 구분함 프로세스 task_struct task_struct run queue CPU 를사용한후에는 wait queue 로이동! 프로세스 task_struct (*) scheduler 의 time complexity 는 O(1) 임 (CFS: Completely Fair Scheduler)

1. Task & Scheduling & Preemption(4) - schedule 함수 (*) schedule(), waitqueue, runqueue 등의개념을정확히이해하면앞으로설명하게될 bottom half & deferring work 관련코드를이해하는데도많은도움이될수있겠다 ^^ schedule( ) : runqueue 에서 process(task) 를하나꺼내어, 그것을 CPU 에게할당해주는것을의미 (scheduler 가작업해줌 ). 여러 kernel routine 에의해서직 / 간접적으로호출됨. < 직접호출방법요약 > 1) Insert current in the proper wait queue. current process(task) 를 wait queue 에넣어둠. 2) Changes the state of current either to TASK_INTERRUPTIBLE or to TASK_UNINTERRUPTIBLE. current process 의상태를 TASK_INTERRUPTIBL 혹은 TASK_UNINTERRUPTIBLE 로지정함. 3) Invokes schedule( ). schedule 함수를호출함. 즉, 다른 process(task) 에게 CPU 를사용할기회를줌. 4) Checks if the resource if available; if not, goes to step 2. current process 가사용할 resource 가사용가능한지체크하여, 없으면 2 로 jump 하여대기함. 5) Once the resource is available, removes current from the wait queue. current process 가사용할 resource 가사용가능하면, current process 를 wait queue 에서빼냄 (runqueue 로이동함 ).

1. Task & Scheduling & Preemption(5) - sleeping & waking up /* 아래코드에서 q 는 wait queue 임 */ (*) 아래내용은이전 page 의내용을 Sleeping & Waking up 관점에서다시정리한것임. DEFINE_WAIT(wait); 매크로를이용하여 wait queue entry 를하나생성함. add_wait_queue(q, &wait); 자신을 wait queue 에넣는다. Wait queue 는깨어날조건이발생할때, 해당 process 를깨운다. while (!condition) { /* condition is the event that we are waiting for */ prepare_to_wait(&q, &wait, TASK_INTERRUPTIBLE); process 상태를 TASK_INTERRUPTIBLE 로바꾼다. if (signal_pending(current) /* handle signal */ wakeup signal 이도착하면, process 는깨어날수있는상태가된다. 여기서 signal 을처리하고, while loop 을빠져나오게됨. schedule(); wakeup 할조건이성립되지않으면, 해당 process 는여전히 sleep 한다. ( 즉, 다른 process 가 CPU 를사용할수있도록 schedule 함수를호출 ) } finish_wait(&q, &wait); 깨어나기위해자신을 wait queue 에서제거한다.

1. Task & Scheduling & Preemption(6) - preemption (*) linux kernel(2.6 이상 ) 은 interrupt, system call, multiprocessor 등의다양한상황에서 fully preemptive 하다. 즉, 임의의 task 가현재실행중인 task 로부터 CPU 를빼앗을수있다. (*) preemption 되면 runnable task 가다른 task 로교체 (context switching) 됨. Virtual memory (resource) User application Critical region CPU1 CPU2 userspace kernel System call Critical region Interrupt kernel Interrupt handler interrupt tasklet Kernel thread (*) user preemption 시점 1) System call 후, user space 로복귀시 2) Interrupt handler 처리후, user space 로복귀시 devicce scheduler (*) kernel preemption 시점 4 장 55 page 참조

다음장으로넘어가기전에 <work 정의 > 1) task 2) some function routines : interrupt handler, softirq, tasklet, work queue, timer function (*) 앞으로설명할 task/scheduling, top/bottom halves, timer routine 등은모두아래와같은형태로일반화시켜생각해볼수있을듯하다. 너무일반화시켰나 ^^ (*) 한가지재밌는것은이러한구조는 kernel 내에서뿐만아니라, Android UI 내부 Message 전달구조및 media framework 의핵심인 stagefright event 전달구조에서도유사점을찾을수있다는것이다 ^^. < 실행요청 > 1) schedule 2) Interrupt 3) it s own schedule func < 처리루틴 > w/, w/o queue 1) runqueue, waitqueue 2) work queue 3) irq queue(interrupt) 4) tasklet queue 5) Timer queue <queue 에서가져옴 > 1) scheduler 2) interrupt handling, tasklet processing, timer processing, 3) worker thread, Thread for threaded Interrupt handler

2. Top Half, Bottom Halves and Deferring Work - 개념 1) Interrupt handler 를 top half 라고하며, 지연처리 (deferring work) 가가능한루틴을 bottom half 라고함. 지연처리는 interrupt context(tasklet) 에대해서도필요하며, process context(work queue) 에도필요하다. 2) (bottom half 중에서도 ) 해당작업이 sleep 가능하거나 sleep 이필요할경우 : work queue 사용 process context 에서실행 3) 1 의조건에해당하지않으며빠른처리가필수적인경우 : tasklet 사용 interrupt context 에서실행 Softirq 도 tasklet 과동일한구조이나, 사용되는내용이정적으로정해져있음. 따라서 programming 시에는동적인등록이가능한 tasklet 이사용된다고이해하면될듯 ^^ 4) tasklet 과 softirq 의관계와마찬가지로, work queue 는 kernel thread 를기반으로하여구현되어있음. 5) Threaded interrupt handler 를사용하면, real-time 의개념이들어간 thread 기반의 interrupt handling 도가능하다. work queue 와는달리, 우선순위가높은 interrupt 요청시, 빠른처리가가능하다. work queue 가있음에도이개념이등장한이유는, interrupt handler 내에서처리할작업은시간이오래소요되지만, 마치 top half 처럼바로처리할수없을까하는생각 ( 요구 ) 에서나온듯함 ^^.

2. Top Half, Bottom Halves and Deferring Work - 개념 CPU Interrupt handler(top half) Device interrupt I S R Tasklet( 지연가능, sleep 불가능 ) Work Queue( 지연가능, sleep 가능 ) kernel thread 와연계 Threaded interrupt handler ( 지연가능, sleep 가능, Real-time) Bottom half (*) 위의그림에서처럼, tasklet, work queue, threaded interrupt handler routine 모두 interrupt handler 내에서지연처리를위해사용될수있는방식들이다. (*) 다만, tasklet 은 interrupt context 에서수행되며, work queue 및 threaded interrupt handler 는 process context 에서수행되므로, 지연시킬작업의내용을보고, 어떤방식을사용해야할지결정해야한다. (*) work queue 는 bottom half 개념으로등장하기는했으나, 위에서와같이 interrupt handler 내에서의지연처리뿐만아니라, 임의의 process context 에대한지연처리시에도널리활용되고있다.

2. Top Half, Bottom Halves and Deferring Work interrupt context 지연 <Interrupt Handler> (1) 처리요청 Top half (2) 즉시 return Interrupt Request (1) 처리요청 (3) 즉시 return (2) 추가작업처리요청 Bottom half more works after some delay (*) Top half 의경우는바로처리가능한 interrupt handler 를의미하며, Bottom half 는시스템의반응성 (interrupt 유실방지 ) 을좋게하기위하여, 시간이오래걸리는작업을별도의루틴을통해나중에처리하는것을일컫는다. 어쨌거나, interrupt handler 내에서처리할작업이좀있는경우에는 bottom half 처리루틴에게일을넘겨주고, 자신은빨리 return 하므로써, 다음 interrupt 의유실을최대한막을수있는것으로이해하면될듯 ^^

2. Top Half, Bottom Halves and Deferring Work process context 지연 Process Context (work) request processing for the work after some delay work queue Kernel thread (*) softirq/tasklet 이 interrupt 처리지연과관련이있다면, work queue 는 process context 지연과관련이있다. 복수개의요청 (process context) 을 work queue 에등록해둔후, 나중 (after some delay) 에처리하는것으로효율을향상시킬목적으로사용됨 ^^ (*) 따라서앞서이미언급한바와같이, work queue 의경우는 interrupt handler 내에서의지연처리뿐만아니라, 임의의 process context 에대한지연처리에도널리활용되고있다.

2. Top Half, Bottom Halves and Deferring Work bottom halves Threaded interrupt handler (Real-time) Generic Kernel Thread Work Queue Tasklet & softirq Interrut hanlder 와는무관하게주기적으로수행해야하는 job 을처리하기위한용도로도사용됨 (*) 위의화살표가특별한의미를부여하는것은아님. 다만, deferring work 관련하여대략적으로위와같이발전 ( 진전 ) 하고있는것으로보이며, 따라서본문서에서도위의순서를따라설명을진행하고자함. (*) 가장최근에등장한 Threaded interrupt handler 의경우는 real-time OS 의특징 ( 실시간처리 ) 을지향하고있다.

2. Top Half, Bottom Halves and Deferring Work interrupt & process context/1 <interrupt context(=atomic context) 의제약사항 > (*) user space 로의접근이불가능하다. Process context 가없으므로, 특정 process 와결합된 user space 로접근할방법이없다 ( 예 : copy_to_user(), copy_from_user() 등사용불가 ) (*) current 포인터 ( 현재 running 중인 task pointer) 는 atomic mode 에서는의미가없으며, 관련코드가 interrupt 걸린 process 와연결되지않았으므로, 사용될수없다 (current pointer 에대한사용불가 ). (*) sleeping 이불가하며, scheduling 도할수없다. Atomic code 는 schedule() 함수를 call 해서는안되며, wait_event 나 sleep 으로갈수있는어떠한형태의함수를호출해서도안된다. 예를들어, kmalloc(, GFP_KERNEL) 을호출해서는안된다 (GFP_ATOMIC 을사용해야함 ). Semaphone 도사용할수없다 (down 사용불가. 단, up 이나 wake_up 등다른쪽을풀어주는코드는사용가능함 ) (*) 위의내용은앞으로설명할 interrupt handler 와 tasklet 에모두적용되는내용임. (*) 반대로, work queue 는 process context 에서동작하므로위에서제약한사항을모두사용할수있음 ^^.

2. Top Half, Bottom Halves and Deferring Work interrupt & process context/2 (*) user application 에의해발생하는 system call 을처리하는 kernel code 의경우 process context 에서실행된다고말함. process context 에서실행되는 kernel code 는다른 kernel code 에의해 CPU 사용을빼앗길수있다 (preemptive) process context 대상 : user process 로부터온 system call 처리, work queue, thread, threaded interrupt handler (*) 반면에 interrupt handler( 얘가전부는아님 ) 를 interrupt context 라고이해하면쉬울듯. interrupt context 에서수행되는 kernel code 는끝날때까지다른 kernel code 에의해중단될수없다. interrupt context 대상 : hard interrupt handler, softirq/tasklet Interrupt context 에서해서는안되는일 1) Sleep 하거나, processor 를포기 2) Mutex 사용 3) 시간을많이잡아먹는일 4) User space(virtual memory) 접근

2. Top Half, Bottom Halves and Deferring Work - Interrupt Handler(top half) request_irq( ) hardware yes handle_irq_event( ) allocate an interrupt line generate interrupt Interrupt controller Is there an interrupt handler on this line? run all interrupt handlers on this line CPU interrupts the kernel do_irq( ) no ret_from_intr( ) Linux kernel Return to the kernel code that was interrupted. (*) 보통은 1 개의 handler 를처리하겠으나, shared IRQ 인경우는동시에여러 handler 가몰릴수있다.

2. Top Half, Bottom Halves and Deferring Work - Interrupt Handler(top half) int request_irq(unsigned int irq, irq_handler_t handler, unsigned long flags, const char *name, void *dev); Interrupt handler 등록및실행요청 < 두번째 argument handler> typedef irqreturn_t (*irq_handler_t)(int, void *); (*) /proc/interrupts 에서인터럽트상태를확인할수있음! Interrupt handler H/W interrupt 가발생할때마다호출됨 synchronize_irq() free_irq 를호출하기전에호출하는함수로, 현재처리중인 interrupt handler 가동작을완료하기를기다려줌. free_irq() 인터럽트 handler 등록해제함수 disable_irq() 해당 IRQ 라인에대한 interrupt 리포팅을못하도록함. disable_irq_nosync() Interrupt handler 가처리를끝내도록기다리지않고바로 return 함 enable_irq() 해당 IRQ 라인에대한 interrupt 리포팅을하도록함. *) 인터럽트처리중에또다른인터럽트가들어올수있으니, 최대한빠른처리가가능한코드로구성하게됨.

2. Top Half, Bottom Halves and Deferring Work - Interrupt Handler(top half) <Shared handler 구현시요구사항 > *) 한개의 interrupt line 을여러장치가공유 ( 따라서, interrupt handler 도각각서로다름 ) 할경우에는좀더특별한처리가요구된다. 1) request_irq( ) 함수의 flags 인자로 IRQF_SHARED 를넘겨야한다. 2) request_irq( ) 함수의 dev 인자로는해당 device 정보를알려줄수있는내용이전달되어야한다. NULL 을넘겨주면안된다. 3) 마지막으로 interrupt handler 는자신의 device 가실제로 interrupt 를발생시켰는지를판단할수있어야한다. 이를위해서는 handler 자체만으로는불가능하므로, device 에서도위를위한방법을제공해야하며, handler 도이를확인하는루틴을제공해야한다. Kernel 이 interrupt 를받으면, 등록된모든 interrupt handler 를순차적으로실행하게된다. 따라서, interrupt handler 입장에서는자신의 device 로부터 interrupt 가발생했는지를판단하여, 그렇지않을경우에는재빨리 handler 루틴을끝내야한다.

2. Top Half, Bottom Halves and Deferring Work - Interrupt Handler(top half) <Interrupt Disable/Enable> *) 드라이버로하여금, interrupt line 으로들어오는 interrupt 를금지및다시허용하는것이가능한데, interrupt 를 disable 하게되면, 처리중인 resource 를보호할수있다. *) interrupt handler 를수행하기직전에 kernel 이알아서 interrupt 를 disable 해주고, handler 를수행한후에 interrupt 를다시 enable 시켜주므로, handler routine 내에서는 interrupt 를 disable 해줄필요가없다. disable_irq(irq); local_irq_save(flags); system의모든 processor로부터의 interrupt를금지시킴 ( 해당 IRQ line에대해서만 ) 현재상태저장 handler(irq, dev_id); interrupt handler 루틴구동 local_irq_restore(flags); 저장된상태복구 enable_irq(irq); system의모든 processor로부터의 interrupt를허용함 (*) enable_irq/disable_irq 는항상쌍으로호출되어야한다. 즉, disable_irq 를두번호출했으면 Enable_irq 도두번호출해주어야금지된 interrup 가해제됨. local_irq_disable(); 현재 processor 내부에서만 interrupt 를금지시켜줌. /* interrupts are disabled */ local_irq_enable();

2. Top Half, Bottom Halves and Deferring Work - Interrupt Handler(top half) Interrupt 관련함수 함수의의미 local_irq_disable() Local( 같은 processor 내 ) interrupt 금지. local_irq_enable() local_irq_save() local_irq_restore() disable_irq() disable_irq_nosync() Local interrupt 허용 Local interrupt 의현재상태저장후, interrupt 금지 Local interrupt 의상태를이전상태로복구 주어진 interrupt line( 전체 processor 에해당 ) 에대한 interrupt 금지. 해당 line 에대해 interrupt 가발생하지않는것으로보고 return 함. 주어진 interrupt line( 전체 processor 에해당 ) 에대한 interrupt 금지 enable_irq() 주어진 interrupt line( 전체 processor 에해당 ) 에대한 interrupt 허용 irqs_disabled() Local interrupt 가금지되어있으면 0 이아닌값 return, 그렇지않으면 0 return. in_interrupt() in_irq() 현재코드가 interrupt context 내에있으면, 0 이아닌값 return, process context 에있으면 0 return., 현재 interrupt handler 를실행중이면, 0 이아닌값 return, 그렇지않으면 0 return.

2. Top Half, Bottom Halves and Deferring Work - Interrupt Handler(top half) <Interrupt handler 사용예 >

2. Top Half, Bottom Halves and Deferring Work - Tasklet tasklet list (*) tasklet 과 softirq 의동작원리는동일함. 다만, softirq 는 compile-time 에이미내용 (action) 이정해져있으며, tasklet 은 dynamic 하게등록할수있는형태임. (*) tasklet 은동시에하나씩만실행됨 (count 와 state 값을활용 ) 이는 multi-processor 환경에서도동일하게적용됨. (*) tasklet 은 task 개념과는전혀무관하며, 또한 work queue 와는달리 Kernel thread 를필요로하지않음 ( 그만큼간단한작업을처리한다고보아야할듯 ^^). my_tasklet my data my_tasklet_handler { } tasklet_schedule(&my_tasklet) 이것이호출되면 tasklet handler 실행됨 reference count, state tasklet_init(&my_tasklet, my_tasklet_handler) or DECLARE_TASKLET(my_tasklet, my_tasklet_handler, my_data) 초기화 (*) tasklet_enable(&my_tasklet) disable 된 tasklet 를 enable 시킬때사용 (*) tasklet_disalbe(&my_tasklet) enable 된 tasklet 를 disable 시킬때사용 (*) tasklet_kill( ) tasklet 를 pending queue 에서제거할때사용 my_tasklet_handler(my_data) will be run! 얘는빠르게처리되는코드이어야함!

2. Top Half, Bottom Halves and Deferring Work - Tasklet <Tasklet scheduling 절차 > 1. Tasklet 의상태가 TASKLET_STATE_SCHED 인지확인한다. 만일그렇다면, tasklet 이이미구동하도록 schedule 되어있으므로, 아래단계로내려갈필요없이즉시 return 한다. 2. 그렇지않다면, tasklet_schedule( ) 함수를호출한다. 3. Interrupt system 의상태를저장하고, local interrupt 를 disable 시킨다. 이렇게함으로써, tasklet_schedule( ) 함수가 tasklet 를조작할때, 다른것들과엉키지않게된다. 4. Tasklet 을 tasklet_vec(regular tasklet 용 ) 이나 tasklet_hi_vec(high-priority tasklet 용 ) linked list 에추가한다. 5. TASKLET_SOFTIRQ 혹은 HI_SOFTIRQ softirq 를발생 (raise) 시키면, 잠시후 do_softirq( ) 함수에서이 tasklet 을실행하게된다. do_softirq( ) 는마지막 interrupt가 return할때실행하게된다. do_softirq( ) 함수내에서는 tasklet processing의핵심이라할수있는 tasklet_action( ) 및 tasklet_hi_action() handler를실행하게된다. 이과정을다음페이지에상세하게정리 6. Interrupt 를이전상태로복구하고, return 한다.

2. Top Half, Bottom Halves and Deferring Work - Tasklet <Tasklet handler 수행절차 > 1. Local interrupt delivery 를 disable 시킨후, 해당 processor 에대한 tasklet_vec 혹은 tasklet_hi_vec 리스트정보를구해온다. 이후, list 를 clear(null 로셋팅 ) 시킨후, 다시 local interupt delivery 를 enable 시킨다. 2. 1 에서얻은 list 를구성하는각각의 (pending) tasklet 에대해아래의내용을반복한다. 3. CPU 가두개이상인 system 이라면, tasklet 이다른 processor 상에서동작중인지체크한다 (TASKLET_STATE_RUN 플래그사용 ). 만일그렇다면, tasklet 을실행하지않고, 다음번 tasklet 을검사한다. 4. Tasklet 이실행되지않고있으면, TASKLET_STATE_RUN 플래그값을설정한다. 그래야다른 procssor 가이 tasklet 을실행하지못하게된다. 5. Tasklet 이 disable 되어있지않은지를확인하기위해 zero count 값을검사한다. 만일 tasklet 이 disable 되어있으면, 다음 tasklet 으로넘어간다. 6. 이제 tasklet 을실행할모든준비가되었으므로, tasklet handler 를실행한다. 7. Tasklet 을실행한후에는 TASKLET_STATE_RUN 플래그를 clear 한다. 8. 이상의과정을모든 pending tasklet 에대해반복한다.

2. Top Half, Bottom Halves and Deferring Work - Tasklet (*) 아래 code 는 softirq 및 tasklet 을실제로처리해주는 ksoftirqd kernel thread 의메인루틴을정리한것임. (*) softirq or tasklet 이발생할때마다실행하게되면, kernel 수행이바빠지므로, user space process 가처리되지못하는문제 (starvation) 가있을수있으며, interrupt return 시마다실행하게되면, softirq(tasklet) 처리에문제 (starvation) 가발생할수있어, 해결책으로써, ksoftirqd kernel thread 를두어처리하게됨. (*) ksoftirqd 는평상시에는낮은우선순위로동작하므로, softirq/tasklet 요청이많을지라도, userspace 가 starvation 상태로빠지는것을방지하며, system 이 idle 상태인경우에는 kernel thread 가즉시 schedule 되므로, softirq/tasklet 을빠르게처리할수있게된다. ksoftirqd 의메인루틴 for (;;) { if (!softirq_pending(cpu)) schedule( ); set_current_state(task_running); while (softirq_pending(cpu)) { do_softirq( ); if (need_resched( )) schedule( ); } set_current_state(task_interruptible); }

2. Top Half, Bottom Halves and Deferring Work - Tasklet <data structure 일부발췌 include/linux/interrupt.h>

2. Top Half, Bottom Halves and Deferring Work - Tasklet <tasklet 사용예 >

2. Top Half, Bottom Halves and Deferring Work - Work Queue(default) <my work work_struct> data func (work handler) (*) work queue 라고하면, work, queue, worker thread 의세가지요소를통칭함. (*) work queue 를위해서는반드시 worker thread 가필요함. (*) 기정의된 worker thread(events/0) 를사용하는방식과새로운 worker thread 및 queue 를만드는두가지방법이존재함. (*) work queue 에서사용하는 work 는 sleep 이가능하다. (*) worker thread 관련보다자세한사항은 kernel/workqueue.c 파일참조 <worker thread> Set task state to TASK_INTERRUPTIBLE schedule_work or schedule_delayed_work < 기정의된 work thread 를사용하는경우 > work queue schedule_work( ) 엔트리를 work queue 에추가함 schedule_delayed_work( ) 엔트리를 work queue 에추가하고, 처리를지연시킴 flush_scheduled_work( ) work queue 의모든엔트리를처리 ( 비움 ). 모든 entry 가실행됨. Entry 를취소하는것이아님 ( 주의 ). 또한 schedule_delayed_work 은 flush 시키지못함. cancel_delayed_work( ) delayed work( 엔트리 ) 를취소함. Add itself(thread) to wait queue ( sleep) If work list is empty then schedule Else set task state to TASK_RUNNING Remove itself from wait queue ( wakeup) Run work queue 여기서 func 함수호출됨 loop

2. Top Half, Bottom Halves and Deferring Work - Work Queue( 사용자정의 ) < 사용자정의 work queue 관련 API 모음 > struct workqueue_struct *create_workqueue(const char *name); 사용자정의워크큐및 woker thread 를생성시켜줌. queue_work( ) my work queue int queue_work(struct workqueue_struct *wq, struct work_struct *work); 사용자정의 work 을사용자정의 work queue 에넣고, schedule 요청함. my work void flush_workqueue(struct workqueue_struct *wq); 사용자정의 work queue 에있는모든 work 을처리하여, queue 를비우도록요청 my thread my work Delayed work 관련 API 는다음페이지참조 (create_workqueue 에인수로넘겨준 name 값이 thread name 이됨 ps 명령으로확인가능 ) (*) 사용자정의 work queue 를생성하기위해서는 create_workqueue() 를호출하여야하며, queue_work() 함수를사용하여 work 을 queue 에추가해주어야한다. (*) 보통은기정의된 work queue 를많이활용하나, 이는시스템의많은 driver 들이공동으로사용하고있으므로, 경우에따라서는원하는결과 ( 성능 ) 를얻지못할수도있다. 따라서이러한경우에는자신만의독자적인 work queue 를만드는것도고려해보아야한다. (*) 보다자세한사항은 include/linux/workqueue.h 파일참조

2. Top Half, Bottom Halves and Deferring Work - Work Queue( 사용자정의 ) <Delayed work queue 관련 API 모음 > struct delayed_work { struct work_struct work; struct timer_list timer; }; work 과 timer 를묶어새로운 data structure 정의! int schedule_delayed_work(struct delayed_work *work, unsigned long delay); 주어진 delay 값만큼해당 work 을지연시켜실행 예 ) mmc driver 에서발췌한루틴 static struct workqueue_struct *workqueue; // 선언 { } queue_delayed_work(workqueue, work, delay); // delayed work 요청 int cancel_delayed_work(struct delayed_work *work); 앞서설명한 schedule_delayed_work 으로선언한 work 을중지 ( 취소 ) void flush_delayed_work(struct delayed_work *work); 사용자정의 work queue 에있는모든 delayed work 을처리하여, queue 를비우도록요청 (*) create_workqueue() 함수의 argument 값에따라 4 가지의 macro 가존재함!!! 자세한사항은 workqueue.h 파일참조 { flush_workqueue(workqueue); // work queue에있는모든 flush 요청 (delayed work에대한 flush 아님 ) } { } workqueue = create_freezeable_workqueue( kmmcd ); // work queue 생성 destroy_workqueue(workqueue); // work queue 제거

2. Top Half, Bottom Halves and Deferring Work - Work Queue(data structure) struct workqueue_struct { struct cpu_workqueue_struct cpu_wq[nr_cpus]; struct list_head list; const char *name; int singlethread; int freezeable; int rt; }; <work queue 관련 data structure> struct cpu_workqueue_struct { spinlock_t lock; struct list_head worklist; wait_queue_head_t more_work; struct work_struct *current_struct; struct workqueue_struct *wq; task_t *thread; }; queue_work( ) struct work_struct { atomic_long_t data; struct list_head entry; work_func_t func; }; <work 관련 data structure> my work my work queue my work func <worker thread flow> 1) Thread 자신을 sleep 상태로만들고, wait queue 에자신을추가한다. 2) 처리할 work 이없으면, schedule() 을호출하고, 자신은여전히 sleep 한다. 3) 처리할 work 이있으면, wakeup 상태로바꾸고, wait queue 에서빠져나온다. 4) run_workqueue( ) 함수를호출하여, deferred work 을수행한다. func( ) 함수호출함.

2. Top Half, Bottom Halves and Deferring Work - Work Queue <data structure 일부발췌 include/linux/workqueue.h>

2. Top Half, Bottom Halves and Deferring Work - Work Queue <work queue 사용예 > (*) 아래예는 default(system) work queue 의사용예이며, 사용자정의 work queue 의사용예는앞서이미정리함 ^^.

2. Top Half, Bottom Halves and Deferring Work - Kernel Threads Kernel thread 란? (*) kernel 내에서 background 작업 (task) 을수행하는목적으로만들어진 lightweight process 로, user process 와유사하나 kernel space 에만머물러있으며, kernel 함수와 data structure 를사용하고, user space address 를포함하지않는다 (task_strruct 내의 mm pointer 가 NULL 임 ). (*) 그러나, kernel thread 는 user process 와마찬가지로 schedule 가능하며, 다른 thread 에의해선점 (preemtable) 될수있다. (*) 사용자정의 kernel thread 는 kthreadd(parent of kernel threads) 에의해추가생성 (fork) 된다. kthread_create( ) or kthread_run( ) macro 임 kthread_create_list 에자신을추가 int kthreadd(void *unused) { for (;;) { /* 생성할 thread 가없으면, 휴식 */ /* 있으면, 아래루틴수행 */ while (kthread_create_list is not empty) create_kthread(new_thread); } }

2. Top Half, Bottom Halves and Deferring Work - Kernel Threads static void create_kthread(struct kthread_create_info *create) { int pid; } pid = kernel_thread(kthread, create, CLONE_FS CLONE_FILES SIGCHLD); static int kthread(void *_create) { struct kthread_create_info *create = _create; int (*threadfn)(void *data) = create->threadfn; void *data = create->data; ret = threadfn(data); 사용자가등록한 thread function 수행! } do_exit(ret);

2. Top Half, Bottom Halves and Deferring Work - Kernel Threads struct task_struct *kthread_create(my_thread, data, ); Kernel thread 생성 ( 구동은안함 ) 보통은 kthread_run() 을더많이씀 (thread 생성후, 구동시작 ) kthread_stop(tsk); 구동중지 생성및구동 kthread_run( ) kernel thread 를만들고, thread 를깨워줌 kthread_create( ) kernel thread 를만듦 (sleeping 상태로있음 ) kthread_bind( ) thread 를특정 CPU 에 bind 시킬때사용함. kthread_stop( ) thread 를중지할때사용함. Kthread_should_stoip 을위한조건을설정해줌. kthread_should_stop( ) kernel thread 루틴을멈추기위한조건검사함수. int my_thread(void *data) do { /* 특정조건이성립될때까지, 대기 다른코드에서대기조건을해제해주어야함 ( 아래코드는단순예임 */ atomic_set(&cond, 0); wait_event_interruptible(wq, kthread_should_stop() atomic_read(&cond); /* 조건이성립되면, 대기루틴을나와, 실제 action 수행 */ /* 실제 action 수행부 */ } while (!kthread_should_stop()); (*) work queue 가 kernel thread 를기반으로하고있으므로, kernel thread 를직접만들필요없이, Work queue 를이용하는것이보다간편할수있다. (*) 보다자세한사항은 include/linux/kthread.h 파일참조

2. Top Half, Bottom Halves and Deferring Work - Kernel Threads <data structure 일부발췌 include/linux/kthread.h>

2. Top Half, Bottom Halves and Deferring Work - Kernel Threads <kernel thread 사용예 >

2. Top Half, Bottom Halves and Deferring Work Threaded Interrupt Handler int request_threaded_irq(unsigned int irq, irq_handler_t handler, irq_handler_t thread_fn, unsigned long flags, const char *name, void *dev); Interrupt handler & threaded interrupt handler 등록및실행요청 Return 값 : IRQ_NONE, IRQ_HANDLED, IRQ_WAKE_THREAD HOT 0) request_thread_irq() 호출시 irq thread 생성 1) If threaded interrupt comes, wakeup the irq thread. 2) Irq thread will run the <thread_fn>. (*) 이방식은 hardware interrupt 방식과는달리 Interrupt 요청시, handler 함수를 kernel thread 에서처리하므로, bottom half 방식으로보아야할것임 ^^ <irq thread> (*) 2.6.30 kernel 부터소개된기법 (Real-time kernel tree 에서합류함 ) response time 을줄이기위해, 우선순위가높은 interrupt 요청시 context switching 이일어남. (*) interrupt 발생시, hardware interrupt 방식으로처리할지 Thread 방식으로처리할지결정 (handler function) IRQ_WAKE_THREAD 를 return 하면, thread 방식으로처리 Handler thread 를깨우고, thread_fn 을실행함. (*) handler 가 NULL 이고, thread_fn 이 NULL 이아니면, 무조건 Threaded interrupt 방식으로처리함. (*) 이방식은앞서소개한 tasklet 및 work queue 의존재를위협할수있는방식으로인식되고있음 ^^. (*) 자세한사항은 kernel/irq/handle.c, manage.c 파일참조 thread_fn irq/number-name 형태로 thread 명칭이생성됨. ( 예 : irq/11-myirq)

2. Top Half, Bottom Halves and Deferring Work Threaded Interrupt Handler request_threaded_irq( ) hardware yes handle_irq_event( ) allocate interrupt line create irq thread generate interrupt Interrupt controller CPU interrupts the kernel Is there an interrupt handler on this line? do_irq( ) no ret_from_intr( ) run all interrupt handlers on this line irq thread IRQTF_RUNTHREAD wakeup wait_for_threads (= wait queue) Linux kernel Return to the kernel code that was interrupted. (*) IRQ(line) 당 1 개씩의 kernel thread 가생성됨. (*) 문제의 Shared IRQ 의경우는위의그림에서처럼, handle_irq_event() 가모든 interrupt handler 를 irq thread 에게순차적으로던져주게되며, irq thread 가이를받아서하나씩처리하게됨. (*) 문제는 irq thread 가 thread_fn 을처리하느라바쁜경우에는어찌하느냐인데 ( 당연히 ) thread 에게넘어간 task 들이 CPU 를할당못받았으니 wait queue 에서대기하게되겠지

2. Top Half, Bottom Halves and Deferring Work Threaded Interrupt Handler static int irq_thread(void *data) /* IRQ 당한개씩할당되는 irq thread */ { struct irqaction *action = data; current->irqaction = action; while (1) { while (!kthread_should_stop()) { set_current_state(task_interruptible); /* 아래 flag 가켜져있으면, while loop 을빠져나와, irq thread function 수행 */ /* IRQTF_RUNTHREAD 는 handle_irq_event() 에서설정해줌 */ if (test_and_clear_bit(irqtf_runthread, &action->thread_flags)) { set_current_state(task_running); break; } schedule(); /* 할일이없으니, 휴식 */ } raw_spin_lock_irq(&desc->lock); action->thread_fun(action->irq, action->dev_id); raw_spin_unlock_irq(&desc->lock); /* requested_threaded_irq 에서등록한 thread_fun 함수실행 실제 action */ } } /* thread 에서 thread_fn 수행중, 새로운 interrupt 가들어올경우, wait queue 에누적되고, 아래에서이를깨우는듯!!! */ if (wait_queue_active(&desc->wait_for_threads) wake_up(&desc->wait_for_threads); /* wait queue 에대기중인 task 를깨움 */

2. Top Half, Bottom Halves and Deferring Work Threaded Interrupt Handler Shared IRQ 인경우 request_threaded_irq(thread_fn1) 등록 (thread 생성 ) external device1 ( 높은우선순위 ) thread_fn1 do_irq() Shared IRQ handle_irq_event() <irq thread> switching external device2 ( 낮은우선순위 ) wakeup thread wakeup thread thread_fn2 <irq thread> request_threaded_irq(thread_fn2) 등록 (thread 생성 ) (*) work queue 와는달리, threaded interrupt handler 를사용하면, 우선순위가높은놈 (?) 이치고들어올경우, 이를바로처리 (real-time) 하는것이가능하다. 그림에서는 interrupt handler 간의 switching 을표현하였으나, interrupt 가들어올경우, CPU 를점유하던임의의낮은우선순위의 task 로부터 CPU 를빼앗는 (preemption) 경우도포함된다. (*) 위의그림에서두개의 thread 를그렸으나, 실제로는같은하나의 thread 임 (IRQ 당 1 개의 thread 만생성됨 )

2. Top Half, Bottom Halves and Deferring Work - ps Kernel thread daemon ( 모든 kernel thread 의 parent) Softirq/tasklet 을위한 Kernel thread Work queue 의한형태 (usermodehelper kernel 에서 User process 실행 역할수행 Default work queue thread (worker thread) (*) 위에는표시되지않았으나, 사용자정의 work queue 를만들경우혹은 kernel thread 를생성할경우, 자신만의 work queue 혹은 kernel thread 가 ps 결과로보이게될것임 ^^ (*) ksoftirqd/0 와 events/0 의 0 은첫번째 processor 를의미함.

3. Timer(1) (*) 앞서설명한 bottom half 의목적은 work 을단순히 delay 시키는데있는것이아니라, 지금당장 work 을실행하지않는데있음. 한편 timer 는일정한시간만큼 work 을 delay 시키는데목적이있음! Bottom half(threaded interrupt handler 는예외 ) 의경우는 delay 시간을보장받기힘들다 ^^. (*) timer 는 timer interrupt 를통해동작하는방식을취함 (software interrupt). 즉, 처리하려는 function 을준비한후, 정해진시간이지나면 timer interrupt 가발생하여해당 function 을처리하는구조임. (*) timer 는 cyclic( 무한반복 ) 구조가아니므로, time 이경과하면 timer function 이실행되고, 해당 timer 는제거된다. Timer interrupt timer_list run_timer_softirq( ) timer_list 실행 timer_list timer_list <timer list 관련 data structure> struct timer_list { struct list_head entry; unsigned long expires; void (*function)(unsigned long); unsigned long data; struct tvec_t_base_s *base; }; timer vector timer_list

3. Timer(2) timer list my_timer my data (*) timer 를 deactivation 시키는함수에는 del_timer() 와 del_timer_sync() 가있음. (*) del_timer_sync() 는현재실행중인 timer handler 가끝날때까지기다려준다. 따라서대부분의경우에이함수를더많이사용한다. 단, 이함수의경우는 interrupt context 에서는사용이불가하다. my_timer_handler { } expired time (3) add_timer() or mod_timer( ) 이를호출하여반복적으로 timer 를돌릴수있음 mod_timer 는 expiratoin 값을변경함은물론이고, Timer 를 activation 시켜준다. Time expired interrupt 시호출됨 void init_timer(struct timer_list *timer); or TIMER_INITALIZER(_function, _expires, _data) (1) 초기화 my_timer.expires = jiffies + delay; my_timer.data = my_data; my_timer.function = my_timer_handler; (2) 설정 my_timer_handler(my_data) will be run! 얘는빠르게처리되는코드이어야함! Softirq 와같은 bottom half conntext 임

3. Timer(3) schedule_timeout (timeout): 현재실행중인 task 에대해 delay 를줄수있는보다효과적인방법. 이방법을사용하면현재실행중인 task 를지정된시간이경과할때까지 sleep 상태 (wait queue 에넣어줌 ) 로만들어주고, 시간경과후에는다시 runqueue 에가져다놓게함. schedule_timeout( ) 의내부는 timer 와 schedule 함수로구성되어있음. schedule_timeout (signed long timeout) { timer_t timer; unsigned long expire; expire = timeout * jiffies; init_timer(&timer); timer.expires = expire; timer.data = (unsigned long)current; timer.function = process_timeout; add_timer(&timer); schedule(); del_timer_sync(&timer); } timeout = expire jiffies; (*) schedule_timeout 말고도, process scheduling 과조합한타이머리스트관련함수로는아래와같은것들이있다. process_timeout(), sleep_on_timeout(), interruptible_sleep_on_timeout()

3. Timer(4) - msleep void msleep(unsigned int msecs) { unsigned long timeout = msecs_to_jiffies(msecs) + 1; } while (timeout) timeout = schedule_timeout_uninterruptible(timeout); (*) msleep 도나쁘지않군요. 내부적으로는 schedule_timeout function 을쓰네요. 다만차이점이있다면, uninterruptible 로되어있어, 주어진시간만큼은확실이 sleep 상태에있겠네요. (*) 참고로, 이와유사한 msleep_interruptible( ) 을쓰면, sleep 하고있다가, wakeup 조건 ( 다른 task 들이놀고있어, 내게차례가올경우 ) 이될경우, 주어진시간을다채우지않은상태에서도깨어날수있습니다 ^^.

3. Timer(5) <data structure 일부발췌 include/linux/timer.h>

3. Timer(6) <timer 사용예 >

4. Synchronization(1) Concurrency(& Pseudo concurrency) 상황 (*) 아래와같은 concurrency 상황이발생할수있으며, 동시에실행가능한상황에처해있는코드는적절히보호되어야한다. Interrupts: interrupt 는아무때나발생 (asynchronously) 하여, 현재실행중인코드를중단시킬수있다. Softirqs & tasklet: 얘들은 kernel 이발생시키고, schedule 하게되는데, 얘들도거의아무때나발생하여현재실행중인코드를중단시킬수있다. 1) SMP 2) Interrupt handlers 3) Preempt-kernel 4) Blocking methods Kernel preemption: 글자그대로한개의 task 가사용하던 CPU 를다른 task 가선점 (CPU 를차지 ) 할수있다 (linux 2.6 부터는 fully preemptive). Sleeping and synchronization with user-space: kernel task 는 sleep 할수있으며, 그사이 user-process(system call) 가 CPU 를차지할수있다. Critical Regions Symmetrical multiprocessing: 두개이상의 processor(cpu) 가동시에같은 kernel code 를실행할수있다. <Kernel preemption 이발생하는경우 > 1) Interrupt handler 가끝나고, kernel space 로돌아갈때 2) Kernel code 가다시 preemptible 해질때 ( 코드상에서 ) 3) Kernel task 가 schedule( ) 함수를호출할때 4) Kernel task 가 block 될때 ( 결국은 schedule( ) 함수를호출하는결과초래 )

4. Synchronization(2) Coding 시주의사항 /1 1) Global data 인가? 즉, 여기말고다른곳 (thread of execution) 에서도이 data 에접근이가능한가? 2) Process context 와 interrupt context 에서공유가가능한 data 인가? 3) 아니면, 두개의서로다른 interrupt handler 에서공유가가능한 data 인가? 4) Data 를사용하던중에다른 process 에게 CPU 를뺏길경우, CPU 를선점한 process 가그 data 를 access 하지는않는가? 5) 현재 process 가 sleep 하거나 block 될수있는가? 만일그렇다면, 이때사용중이던 data 를어떤상태로내버려두었는가? 6) 내가사용중이던 data 를해제하려고하는데, 이를누군가가막고있지는않은가 ( 사용할수있지는않은가 )? 7) 이함수를시스템의다른 processor(cpu) 에서다시호출한다면어떻게되는가? 8) 내가짠 code 가 concurrency 상황에안전하다고확신할수있는가?

4. Synchronization(3) Coding 시주의사항 /2 <Case 1> <Case 2> <Case 3> <Case 4> <Case 5> <case 6> A) process context B) Tasklet A) Tasklet B) Tasklet A) Softirq B) interrupt A) Interrupt B) Interrupt A) Work queue B) Kernel thread A) Kernel thread B) Interrupt 비고 local_irq_disable 사용해야함. A 가 B 에의해선점될수있는가? yes no yes yes yes yes spin_lock_bh (bottom half 간 ) mutex (process context 보호시 ) A 의 critical section 이다른 CPU 에의해접근될수있는가? yes yes yes yes yes yes spin_lock 사용해야함. 1) Interrupt handler 가실행중일때, 다른 interrupt handler 들이저절로 block 되는것은아니다. 단, 같은 interrupt line 은 block 을시킴. 2) 한 CPU 의 interrupt 가 disable 되었다고, 다른 CPU 의 interrupt 가 disable 되는것은아니다. 3) softirq(tasklett) 는다른 softirq 를선점하지는않는다.

4. Synchronization(4) Coding 시주의사항 /3 User application userspace System call kernel CPU2 Interrupt kernel Interrupt handler lock CPU1 Interrupt kernel tasklet Critical region Critical region Kernel thread unlock (*) system call 은임의의시점에서발생할수있다. (*) interrupt 도임의의시점 (asynchronously) 에발생할수있으며, CPU 가두개이상일경우, 각각의 CPU 로부터동시에서로다른임의의 Interrupt 가발생할수있다. Linux kernel 은 fully preemptive 한특성을가지고있으므로, 각각의경우에 kernel code 에서 shared data 를사용하고있다면, 처리에신중을기해야할것임.

4. Synchronization(5) Sync. Methods Kernel Synchronization Methods 내용요약 / 특징 Interrupt context process context Atomic operations Spin Locks Reader-Writer Spin Locks Semaphores Reader-Writer Semaphores Mutexes Completion Variables BKL(Big Kernel Lock) Sequential Locks Preemption Disabling Barriers Low overhead locking Short lock hold time Need to lock from interrupt context Long lock hold time Need to sleep while holding lock

4. Synchronization(6) - Sleeping & Wait Queue wait_event ( 대기상태로빠짐 ) wait queue X task wakeup (CPU 를할당받을수있게됨 ) Critical section O run queue

4. Synchronization(7) - Sleeping & Wait Queue (*) 아래그림은앞페이지의그림을 race condition 관점에서다시그린것이다. (*) 동일한 resource 를두개의서로다른 code 가 access 할수있는상황에서, <A routine> 에게높은우선순위를부여하고자할경우에는, 아래와같이 <B routine> 은 wait_event( ) 함수를호출하여대기상태로진입해야하며, <A routine> 은작업을마친후 wakeup() 를호출하여, <B routine> 이대기상태를벗어나도록해주어야한다. A routine ( 먼저처리작업 ) B routine ( 나중처리작업 ) wakeup( ) 작업처리후, 이함수호출 wait_event( ) 작업진입직전에이함수호출 wakeup( ) 이호출되면, 다음단계로진입가능 access Common resources access

4. Synchronization(8) - Sleeping & Wait Queue (*) wait queue 는 kernel mode 에서 running 중인 task 가특정조건이만족될때까지기다려야할때사용된다. (*) task 가필요로하는특정조건이나 resource 가준비될때까지, 해당 task 는 sleep 상태에있어야한다. < 변수선언및초기화 > wait_queue_head_t wq; init_waitqueue_head(&wq); or DECLARE_WAIT_QUEUE_HEAD(wq); <Going to Sleep critical section으로들어가기전에대기상태로빠짐 > wait_event (wait_queue_head_t wq, int condition) wait_event_interruptible (wait_queue_head_t wq, int condition) wait_event_killable (wait_queue_head_t wq, int condition) wait_event_timeout (wait_queue_head_t wq, int condition, long timeout) wait_event_interruptible (wait_queue_head_t wq, int condition, long timeout) <Waking Up critical section으로들어가는조건을만들어줌 ( 풀어줌 )> void wake_up (wait_queue_head_t *wq); void wake_up_interruptible (wait_queue_head_t *wq); void wake_up_interruptible_sync (wait_queue_head_t *wq);

4. Synchronization(9) - Sleeping & Wait Queue <Wait Queue 사용예 >

4. Synchronization(10) - Completion write 후, complete() 호출 ( 대기해제 ) Read 전, wait_for_completion 호출 ( 대기상태진입 ) Common resources (critical section) struct completion { unsigned int done; wait_queue_head_t wait; }; void init_completion(struct completion *c); /* DECLARE_COMPLETION(x) 도사용가능 */ completion 초기화 void wait_for_completion(struct completion *c); /* timeout 함수도있음 */ critical section 에들어갈때호출 ( 대기를의미함 ) int wait_for_completion_interruptible(struct completion *c); /* timeout 함수도있음 */ critical section 에들어갈때호출 ( 대기를의미함 ). 이함수호출동안에 Interrupt 가능함. void complete(struct completion *c); critical section 에들어갈수있도록해줌 ( 대기조건을해지해줌 ) void complete_and_exit(struct completion *c, long code);

4. Synchronization(11) - Completion <completion 사용예 >

5. Communication schemes between kernel & userspace : ioctl, proc, signal, sysfs, uevent, mmap

(*) 다음페이지로넘어가지전에 shmem, ashmem & binder uevent mmap sysfs UNIX signal procfs debugfs tmpfs read/write/ioctl (*) 위의화살표가어떤특별한상관관계를표현하고있지는않으며, 본장에서설명하고자하는전체내용을보여주기위해단순히연결해두었을뿐임을주지하기바란다 ^^. (*) 본문서에서는 android 의중요한주제인 binder 에관해서는별도로정리하지않는다. (*) 위의내용중, read/write/ioctl/procfs 등은기본적인사항이라별도로설명하지않는다.

5.1 Send signal from kernel to userspace User process 수신한 signal 에대한 signal handler 를정의하여사용 (*) ioctl 이나 proc(write) 등을통해사전에 pid 값을내려준다. Userspace kernel send_sig(int signal, struct task_struct *tsk, int priv); device driver signal = UNIX signal(ex: SIGUSR1) tsk = pid_task(find_vpid(sig_pid), PIDTYPE_PID); ( 단, sig_pid 는 user process 에서넘겨받은값으로부터계산한값임 ) priv: 0 user process, 1: kernel (device driver 는 user process 의 pid 를사전에알고있어야함 ) (*) kernel(device driver) 내에서특정한사건이발생할경우, 이를특정 application process 에게바로알려주면매우효과적인경우가있을수있다. 예 ) video decoder driver 에서 buffering 에문제발생시, mediaserver 에게이를알려준다 (*) 위의 send_sig 관련자세한사항은 kernel/signal.c 및 include/linux/signal.h 파일참조!!!

5.2 kobjects & sysfs(1) - 개념 subsystem kset kobj kobj kobj kobj kobj < 관련 API 모음 (arguments 생략함 )> kobject_init( ) kobject_create( ) kobject_add( ) kobject_del( ) kobject_get( ) kobject_put( ) sysfs_create_dir( ) sysfs_remove_dir( ) sysfs_rename_dir( ) sysfs_create_file( ) sysfs_remove_file( ) sysfs_update_file( ) sysfs_create_link( ) sysfs_remove_link( ) sysfs_create_group( ) sysfs_remove_group( ) sysfs_create_bin_file( ) sysfs_remove_bin_file( ) (*) kobject(kernel object) 는 device model 을위해등장한것 Kset 은 kobject 의묶음이고, subsystem 은 kset 의묶음임. (*) sysfs 는 kobject 의계층 tree 를표현 (view) 해주는 memory 기반의 file system 으로 2.6 에서부터소개된방법 kernel device 와 user process 가소통 ( 통신 ) 하는수단. 이와유사한것으로 proc file system 등이있음. (*) kobject 관련자세한사항은 include/linux/kobject.h 파일참조, sysfs 관련자세한사항은 include/linux/sysfs.h 파일참조!!!

5.2 kobjects & sysfs(2) - 개념 Internal Kernel Objects Object Attributes Object Relationships (*) sysfs는실제로 /sys 디렉토리에생성됨. External Directories Regular Files Symbolic Links

5.2 kobjects & sysfs(3) 간단한사용법 (*) 앞서언급한 kobject_ 및 sysfs_ API 를이용하여직접작업하는것도가능하나, 보다편리한방법으로위의 API 사용이가능함! 앞서제시한 API 를사용할경우, 매우세세한제어가가능할것임. (*) 드라이버초기화시, device_create_file( ) 을통해 sysfs 파일생성이가능하며, 드라이버제거시, device_remove_file( ) 을통해만들어둔, sysfs 파일이제거된다. (*) device_create_file( ) 로만들어둔, file 을읽고, 쓸경우에는각각 show 및 store 에정의한함수가불리어질것이다. (*) platform device 의경우에는, device_create_file 의첫번째 argument 값으로.dev 필드의정보가전달되어야한다. (*) 위의 API 관련보다자세한사항은 include/linux/device.h 파일참조!!!

5.2 kobjects & sysfs(4) - 사용예 <sysfs 사용예 >

5.2 kobjects & sysfs(5) uevent 0) init 이실행시켜주며, ueventd.{hardware}.rc 파일사용 1) Socket 을열고, 대기 2) Event 수신후, sysfs 내용을참고하여 device 파일생성혹은삭제 (hotplug) Device 생성 ueventd netlink socket Userspace device driver kernel kobject_uevent(struct kobject *kobj, enum kobject_action action); action 은 event 를의미 socket buffer(sk_buffer) 를하나만들어서위로던짐 (?) (*) 다른통신 (kernel & userspace) 방법에비해, socket 을이용하므로매우편리하다.

5.3 virtual memory & mmap(1) - background (*) 아래그림은 MMU 를이용하여 Virtual Memory 를 Physical Memory 로 mapping 하는개념을표현한것임. 물리 memory 가작기때문에가상 memory 기법이도입됨. 32bit CPU 의경우 2^32 = 4GB 의가상주소사용가능 (*) 각각의 process 는자신만의 4GB virtual address space 를사용할수있다. /proc/<pid>/maps 내용을보면, 서로다른 process 가동일한위치 ( 주소 ) 를사용하고있음을알수있음. (*) 아래내용은 mmap 의원리및 android memory map 을이해하기위해필요하다 ^^. < 각각의프로세스별 VirtualMemory> <process #1> Kernel(1GB) User Space(3GB) <process #2> Kernel(1GB) User Space(3GB) Process # 1 MMU Table Process # 2 MMU Table kernel MMU Table MMU <Physical Memory> Process #1 Process #2 kernel

5.3 virtual memory & mmap(2) process(user context) & kernel thread 의차이 (*) 아래그림은프로세스에대한 memory 할당과연관이있는 mm_struct 및 vm_area_struct 를표현해주고있다. (*) kernel thread 는 user context 정보가없는 process 로 task_struct 내의 mm field 값이 NULL 이다. 즉, 아래그림에서빨간색점선부분이없다고보면된다. <userspace> text data heap shared library - text shared library - data stack

5.3 virtual memory & mmap(3) android memory map (*) 아래 User space map 정보는 prelink-linux-arm.map 을참조하여작성한것일뿐, 실제동작중인내용 ( 주소값 ) 은다르다. ( 단, 각영역의순서 / 위치는일치함 ) 0xFFFF FFFF Thread 0 Stack /system/bin/linker 0xBEFF FFFF stack 증가 0xB000 0000 Kernel Area 1GB Shared libraries(native) 0xC000 0000 stack libs heap data text = Java apps & resources : *.apk, *.jar, *ttf User Space 3GB Non-prelinked libraries mmap d stuff 0x4000 0000 Thread Stacks dalvik-heap area 1GB heap 증가 0x0000 0000 <4 GB Virtual Address Space>.text /.data. / heap 0x0000 8000 <3 GB Userspace> 0x0000 0000 Dalvik VM 에서할당하는 heap 의위치는추측일뿐임 ^^

5.3 virtual memory & mmap(4) mmap (*) mmap 을이용할경우, application process 에서메모리복사과정없이, 직접 kernel 공간을사용할수있음. 반면, read/write/ioctl 의경우는 process memory 와 kernel memory 사이에메모리 copy 과정이수반됨. (*) device driver 에서는 mmap( ) 함수내에서 remap_pfn_range( ) 함수를사용하여 kernel memory 를 userspace 주소로 mapping 시켜주어야함. void *mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset); (3) Return pointer 를이용하여 mapped area 에접근가능 (A 영역을이용하지만, 실제로는 B 영역 ( 정확히는 B 영역에대한 physical memory) 을접근하는것임 ) 0xFFFF FFFF 0xC000 0000 Kernel Area B 1GB Userspace kernel (1) mmap area 생성호출 (2) 실제 memory mapping int mmap(struct file *filp, struct vm_area_struct *vma) { remap_pfn_range(vma, vma->vm_start, len, vma->vm_page_prot); } 0x0000 0000 User Space A <4 GB Virtual Address Space> 3GB

5.3 virtual memory & mmap(4) - mmap (*) mmap 생성시 void *mmap( start, lenth, prot, flags, fd, offset ) Userspace (process space) length length Shared memory (kernel space) start: 일반적으로 NULL 사용 prot: 메모리사용권한 (PROT_READ, PROT_WRITE, PROT_EXEC, PROT_NONE) flags: 메모리공유방식 (MAP_FIXED, MAP_SHARED, MAP_PRIVATE) (*) mmap 을해제하고자할경우 int munmap (void *start, size_t length);

5.3 virtual memory & mmap(5) mmap 사용예 Userspace routine Kernel routine

5.3 virtual memory & mmap(6) ashmem Process #1 Userspace (process space) Process #2 Userspace (process space) fd fd length heap Backing file heap length ashmem Kernel Space (*) ashmem 은 (named) shared memory 와유사한기법으로, file descriptor 를통해접근이가능하도록 Google 에서만든공유메모리기법이다. (*) ashmem 을위해서는내부적으로 mmap 개념이들어가게되며, 사용을위해서는 binder 가필요하다. binder 관련해서는다른서적이나문서를참고하시기바람 ^^.

6. Notifier(1) <kernel routine A> { notifier callback 함수정의 notifier callback 함수등록 (*) notifier 는서로다른곳에위치한 kernel code 간에 event 를전송하기위한 mechanism 으로 callback 함수개념으로생각하면이해가쉽다 ^^. (*) 즉, kernel routine A 에서는호출되기를원하는 callback 함수를기술및등록하고, event 발생시점을아는 kernel routine B 에서해당함수를호출해주는것으로설명할수있겠음! } my_callback_func() { } <kernel routine B> { notifier chain register <event 발생시점예 - bluetooth> 1) HCI_DEV_UP(link up 시 ) 2) HCI_DEV_DOWN(linux down 시 ) 3) HCI_DEV_REG 4) HCI_DEV_UNREG 5) HCI_DEV_WRITE( 패킷전송시 ) } notifier chain unregister some_func() { call notifier_callback func 특정 event 발생시점에서호출 }

6. Notifier(2) (*) 자세한사항은 include/linux/notifier.h 파일참조!

6. Notifier(3) <notifier 사용예 >

7. Suspend/Resume and Wakelock(1) (*) 이그림은 Android 전체 power manangement 를이해하기위해첨부하였다. (*) /sys/power/state 파일을통해 kernel 의전원서비스를이용가능함.

7. Suspend/Resume and Wakelock(2) suspend/resume(1) (*) android suspend/resume 관련해서는 reference 문서 [8] 및아래 site 에잘정리되어있음 ^^ http://taehyo.egloos.com/4091452

7. Suspend/Resume and Wakelock(3) suspend/resume(2) Suspend: 1) 프로세스와 task 를 freezing 시키고, 2) 모든 device driver 의 suspend callback 함수호출 3) CPU 와 core device 를 suspend 시킴 Resume: 1) System 장치 (/sys/devices/system) 를먼저깨우고, 2) IRQ 활성화, CPU 활성화 3) 나머지모든장치를깨우고, freezing 되어있는프로세스와 task 를깨움. Early Suspend: google 에서 linux kernel 에추가한새로운상태로, linux 의 original suspend 상태와 LCD screen off 사이에존재하는새로운상태를말한다. LCD 를끄면배터리수명과몇몇기능적인요구사항에의해 LCD backlight 나, G-sensor, touch screen 등이멈추게된다. Late Resume: Early Suspend 와쌍을이루는새로운상태로, 역시 google 에서 linux kernel 에추가하였다. Linux resume 이끝난후수행되며, early suspend 시꺼진장치들이 resume 하게된다. (*) suspend/resume 및 early suspend/late resume 관련내용은아래파일에서확인할수있다. 1) kernel/power/main.c 2) kernel/power/earlysuspend.c 3) kernel/power/wakelock.c 4) arch/arm/mach-xxx/pm..c

7. Suspend/Resume and Wakelock(4) - wakelock (*) wakelock: android 전원관리시스템의핵심을이루는기능으로, 시스템이 low power state 로가는것을막아주는메카니즘 (google 에서만듦 ) 이다. (*) Smart Phone 은전류를많이소모하므로, 항시 sleep mode 로빠질준비를해야한다. (*) wake_lock_init 의인자로넘겨준, name 값은 /proc/wakelocks 에서확인가능함. Declare and init wakelock (wake 잠금변수선언및초기화 ) <wakeup routine> <sleep routine> Start wakelock (wake 잠금시작 ) 여기서부터계속깨어있음 Release wakelock (wake 잠금해제 ) 여기서부터 sleep 가능해짐 Destroy wakelock (wake 잠금변수제거 driver 제거시 )

7. Suspend/Resume and Wakelock(5) - wakelock <Wakelock 관련 API 모음 > [ 변수선언 ] struct wakelock mywakelock; [ 초기화 ] wake_lock_init(&mywakelock, int type, wakelock_name ); type : = WAKE_LOCK_SUSPEND: 시스템이 suspending 상태로가는것을막음 = WAKE_LOCK_IDLE: 시스템이 low-power idle 상태로가는것을막음. [To hold(wake 상태로유지 )] wake_lock(&mywakelock); [To release(sleep 상태로이동 )] wake_unlock(&mywakelock); [To release(sleep 상태로이동 )] wake_lock_timeout(&mywakelock, HZ); [ 제거 ] wake_lock_destroy (&mywakelock);

7. Suspend/Resume and Wakelock(6) wakelock data structure <data structure 일부발췌 include/linux/wakelock.h>

7. Suspend/Resume and Wakelock(7) wakelock 예 <wakelock 사용예 > (*) 위의내용은 drivers/mmc/core/core.c 파일에서발췌한것임.

7. Suspend/Resume and Wakelock(8) wakelock 예 <wakelock 사용예 ( 계속 )>

8. Platform Device & Driver(1) - 개념 1) Embedded system 의시스템의경우, bus 를통해 device 를연결하지않는경우가있음. bus 는확장성 (enumeration), hot-plugging, unique identifier 를허용함에도불구하고... 2) platform driver/platform device infrastructure 를사용하여이를해결할수있음. platform device 란, 별도의 bus 를거치지않고, CPU 에직접연결되는장치를일컬음. bus CPU bus Platform Device 1 Platform Device 2 Platform Device 3

8. Platform Device & Driver(1) - 개념 - platform_device 정의및초기화 - resource 정의 (arch/arm/mach-msm/board- XXXX.c 파일에위치함 ) < 예 bluetooth sleep device> struct platform_device my_bluesleep_device = {.name = bluesleep,.id = 0,.num_resources = ARRAY_SIZE(bluesleep_resources),.resource = bluesleep_resources, }; - platform_driver 정의및초기화 - probe/remove.name 필드 ( bluesleep ) 로상호연결 (drivers/xxxx/xxxx.c 등에위치함 ) (*) drivers/base/platform.c (*) include/linux/platform_device.h 참조 struct platform_driver bluesleep_driver = {.remove = bluesleep_remove,.driver = {.name = bluesleep,.owner = THIS_MODULE, }, };

8. Platform Device & Driver(2) platform driver (*) drivers/serial/imx.c file 에있는 imx serial port driver 를예로써소개하고자함. 이드라이버는 platform_driver structure 를초기화함. (*) init/cleanup 시, register/unregister 하기

8. Platform Device & Driver(3) platform_device (*) 플랫폼디바이스는동적으로감지 (detection) 가될수없으므로, static 하게지정해주어야함. static 하게지정하는방식은 chip 마다다를수있는데, ARM 의경우는 board specific code (arch/arm/mach-imx/mx1ads.c) 에서객체화및초기화 (instantiation) 를진행하게됨. (*) Platform 디바이스와 Platform 드라이버를 matching 시키기위해서는 name( 아래의경우는 "imx-uart") 을이용함.

8. Platform Device & Driver(4) - platform_device( 초기화 ) (*) platform device 는아래 list 에추가되어야함. (*) platform_add_devices() 함수를통해서실제로시스템에추가됨.

8. Platform Device & Driver(5) - platform_device(resource) (*) 특정드라이버가관리하는각장치 (device) 는서로다른 H/W 리소스를사용하게됨. I/O 레지스터주소, DMA 채널, IRQ line 등이서로상이함. (*) 이러한정보는 struct resource data structure 를사용하여표현되며, 이들 resource 배열은 platform device 정의부분과결합되어있음. (*) platform driver 내에서 platform_device 정보 (pointer) 를이용하여 resource 를얻어오기위해서는 platform_get_resource_byname( ) 함수가사용될수있음.

8. Platform Device & Driver(6) - platform_device(device specific data) (*) 앞서설명한 resource data structure 외에도, 드라이버에따라서는자신만의환경혹은데이터 (configuration) 을원할수있음. 이는 struct platform_device 내의 platform_data 를사용하여지정가능함. (*) platfor_data 는 void * pointer 로되어있으므로, 드라이버에임의의형식의데이타전달이가능함. (*) imx 드라이버의경우는 struct imxuart platform data 가 platform_data 로사용되고있음.

8. Platform Device & Driver(7) platform driver(probe, remove) (*) 보통의 probe 함수처럼, 인자로 platform_device 에의 pointer 를넘겨받으며, 관련 resource 를찾기위해다른 utility 함수를사용하고, 상위 layer 로해당디바이스를등록함. 한편별도의그림으로표현하지는않았으나, probe 의반대개념으로드라이버제거시에는 remove 함수가사용됨.

9. Example Drivers : bluesleep(uart), SDIO

JNI 9. Example Drivers : bluetooth sleep mode driver(1) bluetoothd (*) 아래그림은 bluetooth sleep driver 의개념도로써, platform_driver, interrupt handler, GPIO, tasklet, workqueue, timer, wakelock 등의기법을사용하고있다. Sleep mode 일때는닫고, Wakeup mode 일때는열어준다 외부 Bluetooth 장치

9. Example Drivers : bluetooth sleep mode driver(2) Broadcom chip Power on/off switch Qualcomm chip(cpu) off TX RX CTS RTS RX TX RTS CTS workqueue for sleep UART line host_wake/ ext_wake on HOST_WAKE (irq line) host_wake (interrupt) HOST_WAKE tasklet for wakeup EXT_WAKE EXT_WAKE GPIO line (*) bluetooth 가 wakeup 되는조건은위의 HOST_WAKE 가 enable(interrupt) 되는것이외에도실제로 bluetooth packet 이나가고나서발생하는 HCI event(callback) 에기인하기도한다. (*) 전력소모를최소로하기위해, 틈만나면 (?) sleep mode 로진입해야하며, HOST_WAKE 및 EXT_WAKE GPIO pin 이모두사용중이지않을때 (deasserted), sleep 으로들어가게된다. (*) bluetooth sleep mode driver 는 drivers/bluetooth 아래에서확인가능함.

9. Example Drivers : bluetooth sleep mode driver(3) <sleep case> 1) bluesleep_tx_idle일경우, bluesleep_sleep_work을호출함. 여기에서조건 (bluesleep_can_sleep) 체크하여, ext_wake 및 host_wake가모두 1일경우 sleep으로빠진다. <wakeup case> 1) sleep mode로빠질조건이아닐때 ( 즉, 위의 sleep case가아닐경우 ), 깨어난다. 2) bluesleep_hostwake_task 함수에서 host_wake_irq interrupt를받을때깨어난다. bluesleep_hostwake_isr interrupt service routine이호출됨. 3) hci event(bluetooth frame send) 를받고, bluesleep_outgoing_data 함수호출시, ext_wake 값이 1(= sleep 상태 ) 이면, wakeup 하도록 bluesleep_sleep_wakeup 함수호출함 ( 깨어난다 ).

9. Example Drivers : SDIO driver(1) CPU (*) 아래그림은 drivers/mmc 디렉토리에있는내용을정리한것임. 단, msm_sdcc driver 는 Qualcomm chip 전용드라이버로, Code Aurora Forum 에서관련코드를 down 받을수있음 ^^. msm_sdcc(host controller) (*) platform driver( 얘가메인이라고보면될듯 ^^) (*) probe 시 mmc_host 및 operation 을할당하고, 몇가지 interrupt 요청을등록한후, mmc host 를추가해준다. (*) 전체적인흐름을보면, mmc_host 의 operation 중 request() handler 가함수가호출되면서, command, data 등이오고가는구조로되어있다. 자세한사항은다음페이지내용참조! SDIO SD MMC Core (*) msm_sdcc 드라이버에서사용하는코드및 SDIO/SD/MMC protocol layer 관련코드로구성 (*) power management 정책등이구현되어있음 (*) core 에서신규로정의한 kmmcd work queue 는자동 detection 용도로사용됨. Linux kernel WiFi SDIO MMC card SD card (*) 외부 device

9. Example Drivers : SDIO driver (2) (*) msm_sdcc 드라이버초기화 (probe) 과정에서사용되는 mmc_host data structure 의내용및이를초기화하는코드를정리한것임 ^^ (*) include/linux/mmc/host.h 파일참조

9. Example Drivers : SDIO driver (3) (*) 옆의그림은 mmc_host data structure 관련 operation 함수를정리한것이며, 그중, SD/MCC/SDIO 동작 (read/write) 과관련이있는 request handler 에서사용하는 data structure 를아래에정리하였다. (*) include/linux/mmc/host.h 파일참조 (*) include/linux/mmc/coreh 파일참조

9. Example Drivers : SDIO driver (4) (*) 위그림은, 앞서언급한 request handler 의주요 flow 를개념적으로정리한것임 ^^ SD/MMC/SDIO 관련하여 data 를읽고, 쓰는작업과관련있는그림으로보면될듯 cmd 전송후, data 를전달할것이있으면, 전송하고, 전송완료후에는 mmc_request_done 호출! cmd 및 data 전송은실질적으로는주어진주소에값을 write 하는것으로보면됨 ^^.