Android Device Driver Hacks : interrupt handler, tasklet, work queue, kernel thread, synchronization, transferring data between kernel & user space (

Transcription

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

2 목차 * 1. Task & Scheduling & Preemption 2. Top Half, Bottom Halves and Deferring Work Interrupt Handler, Softirq, Tasklet, Work Queue, Interrupt Thread 3. Timer 4. Synchronization 5. Communicatoin schemes between kernel and userspace read/write/ioctl & proc & UNIX signal kobjects & sysfs & uevent mmap & ashmem 6. Suspend/Resume & Wakelock 7. Platform Device & Driver References

3 (*) 본문서가아래의질문에대해적절한답을주고있는가?* 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) Top/bottom half, interrupt/process context, SMP 등각각의상황별 locking 방법이적절히기술되어있는가? 14) Timer 를사용하려면어찌해야하는가? 15) Kernel 과 user process 가통신하려면어찌해야하는가? 16) wakelock, suspend/resume 의개념이잘설명되어있는가? 17) Platform driver 를작성하려면어찌해야하는가?

4 (*) 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 Timer & Hrtimer Concurrency, critical region(section) Synchronization, locking procfs, sysfs mmap ashmem, binder android Resume/suspend/wakelock android Platform device & driver

5 1. Task & Scheduling & Preemption(1) task scheduling* (*) task, wait queue, run queue 간의관계를보여주는그림으로, wake_up 함수가호출되면, 대기중이던해당 task 가 run queue 로이동하여 CPU 를할당받게된다 (Scheduler 가그역할을담당함 ). (*) wait queue, run queue 로의이동은 scheduler 가수행하기도하지만, kernel code(my code) 내에서명시적으로수행하는경우도많다 ^^. wake_up CPU current wait queue wait queue wait queue 프로세스 task_struct run queue 항목이비어있거나, wakeup event 를받을경우, run queue 로이동할수있다. 프로세스 우선순위별로 queue 구분함 ( 실제로는 rbtree) 프로세스 task_struct task_struct run queue 프로세스 task_struct CPU 를사용한후에는 wait queue 로이동! 혹은코드내에서스스로 wait queue 로들어갈수있음. (*) CFS scheduler 의 time complexity 는 O(1) 임 (CFS: Completely Fair Scheduler) - Time accounting, process selection, sleeping & waking up

6 1. Task & Scheduling & Preemption(2) 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 에저장됨 ^^ (*) 참고로, task_struct data structure 는 32bit CPU 기준으로약 1.7KB 의크기 ( 매우큼 ) 를필요로함.

7 1. Task & Scheduling & Preemption(3) task* 1) add_wait_queue 는 task 를 wait queue 에추가하고, task 의상태를 TASK_INTERRUPTIBLE 로변경시킴. 2) 이어호출되는 schedule() 함수는 runqueue 에있는가장우선순위가높은다른 task 를 CPU 에게할당해줌. 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 는특정조건이성립될때까지기다리게된다. (*) 위에서언급된특정함수는버전에따라차이가있을수있음. 단, 전체적인개념은동일함.

8 1. Task & Scheduling & Preemption(4) - sleeping & waking up* (*) 아래코드 style 은 kernel code 이곳저곳에서매우많이사용되므로눈여겨볼것 ^^ (*) 4 장의 synchronization(11 sleeping & wait queue) 내용과도일맥상통하는부분임 ^^. /* 아래코드에서 q 는 wait queue 임 */ DEFINE_WAIT(wait); 매크로를이용하여 wait queue entry 를하나생성함. schedule( ) : runqueue 에서가장우선순위가높은 process(task) 를하나꺼내어, 그것을 CPU 에게할당해주는것을의미 (scheduler 가작업해줌 ). 여러 kernel routine 에의해서직 / 간접적으로호출됨. 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 & break the while loop*/ wakeup signal 이도착하면, process 는깨어날수있는상태가된다. 여기서 signal 을처리하고, while loop 을빠져나오는코드를추가함 ( 보통 ). schedule(); wakeup 할조건이성립되지않으면, 해당 process 는여전히 sleep 한다. ( 즉, 다른 process 가 CPU 를사용할수있도록 schedule 함수를호출 ) } finish_wait(&q, &wait); 깨어나기위해자신을 wait queue 에서제거한다 (runqueue 로이동함. Scheduler 에의해 CPU 를할당받을준비!).

9 1. Task & Scheduling & Preemption(5) preemption* (*) linux kernel(2.6 이상 ) 은 interrupt, system call, multiprocessor 등의다양한상황에서 fully preemptive 하다. 즉, 임의의 task 가현재실행중인 task 로부터 CPU 를빼앗을수있다. (*) preemption 되면 runnable task 가다른 task 로교체 (context switching) 됨. schedule() 함수가호출함. Virtual memory (resource) User application Critical region 3G CPU1 CPU2 userspace kernel System call Critical region 1G 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 참조

10 1. Task & Scheduling & Preemption(6) context switching Process A(ex: mediaserver) main() { } Process B(ex: system_server) main() { } CPU task_struct 1) Registers for process address space 2) PC(Program Counter) 3) SP(Stack Pointer) 4) Some registers task_struct CPU status save restore CPU status kernel stack

11 1. Task & Scheduling & Preemption(7) linux kernel Syscall from userspace (SWI Software Interrupt) main routine Process dispatcher asynchronously 1) 시스템초기화 2) forever loop while (1) { shedule(); } Syscall 처리 routine Scheduling 요청 Schedule Yield Scheduler Process (task) task list Memory management asynchronously Interrupt 처리 routine Kernel thread Hardware interrupt from CPU

12 다음장으로넘어가기전에 * <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

13 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 처럼바로처리할수없을까하는생각 ( 요구 ) 에서나온듯함 ^^.

14 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 에대한지연처리시에도널리활용되고있다.

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

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

17 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 의특징 ( 실시간처리 ) 을지향하고있다.

18 2. Top Half, Bottom Halves and Deferring Work interrupt & process context/1* <interrupt context(=atomic context) 의제약사항 > user app (*) user space 로의접근이불가능하다. Process context 가없으므로, 특정 process 와결합된 user space 로접근할방법이없다 ( 예 : copy_to_user(), copy_from_user() 등사용불가 ) X interrupt handler X current (*) current 포인터 ( 현재 running 중인 task pointer) 는 atomic mode 에서는의미가없으며, 관련코드가 interrupt 걸린 process 와연결되지않았으므로, 사용될수없다 (current pointer 에대한사용불가 ). X sleep or block or schedule (*) 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 에서동작하므로위에서제약한사항을모두사용할수있음 ^^.

19 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, kernel 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) 접근

20 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 가몰릴수있다.

21 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 등록및실행요청 irq( 첫번째 argument) 가 interrupt number 임. < 두번째 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 리포팅을하도록함. *) 인터럽트처리중에또다른인터럽트가들어올수있으니, 최대한빠른처리가가능한코드로구성하게됨.

22 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 루틴을끝내야한다.

23 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();

24 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.

25 2. Top Half, Bottom Halves and Deferring Work Softirqs(soft interrupt handler)* hardware interrupt 와 software interrupt 의예 process Userspace read read data kernel Sleep(wait) wakeup (hard)interrupt handler Soft interrupt handler Hardware interrupt (*) linux 에는두종류의 software interrupt 가있다. bottom half 개념의 soft interrupt 와 system call(swi)!!! 본장에서언급하는내용은 bottom half 개념의 soft interrupt 임.

26 2. Top Half, Bottom Halves and Deferring Work Softirqs(soft interrupt handler)* tasklet_hi_vec tasklet_struct tasklet_struct CPU0 (*func)() (*func)() CPU0 CPU1 CPU1 (*func)() (*func)() softirq_action[ ] tasklet_hi_action() on off HI_SOFTIRQ off on TIMER_SOFTIRQ run_timer_softirq() on off off off on off off on NET_TX_SOFTIRQ NET_RX_SOFTIRQ SCSI_SOFTIRQ TASKLET_SOFTIRQ net_tx_action() net_rx_action() Packet send/recv scsi_softirq() tasklet_action() tasklet_vec tasklet_struct tasklet_struct CPU0 (*func)() (*func)() (*) 이밖에도 4 개정도의추가 SOFTIRQ 가존재함. (BLOCK_IOPOLL, SCHED, HRTIMER, RCU) CPU1 (*func)() (*func)()

27 2. Top Half, Bottom Halves and Deferring Work Softirqs(soft interrupt handler)* Ethernet interrupt (*) 아래중첩 interrupt handler 를처리하기위해 kernel stack 이사용된다. Hard interrupt handler(ethernet) Timer interrupt Soft interrupt handler(tcp/ip) Hard interrupt handler(timer) Timer interrupt Struct thread_info Hard interrupt handler(timer) Soft interrupt (TCP/IP) Timer soft interrupt TCP/IP soft interrupt soft interrupt handler(timer) run_timer_softirq( ) 위에서불린두개의 interrupt 동시처리 Syscall 처리 <kernel stack> time

28 2. Top Half, Bottom Halves and Deferring Work Tasklet* tasklet_init( ) Generate hardware interrupt CPU (1) Interrupt kernel (4) return Interrupt Handler (2) processing (0) tasklet 신규등록 Hardware (3) Request delayed work Software interrupt Ksoftirqd (5) run tasklet (delayed work 이지만, Interrupt context 에서수행 ) Linux kernel

29 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! 얘는빠르게처리되는코드이어야함!

30 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 을빠르게처리할수있게된다. for (;;) { ksoftirqd의메인루틴 if (!softirq_pending(cpu)) /* softirq/tasklet 요청이없으면, sleep */ schedule( ); set_current_state(task_running); while (softirq_pending(cpu)) { do_softirq( ); if (need_resched( )) schedule( ); } /* softirq stack 의내용실행 */ set_current_state(task_interruptible); }

31 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 한다.

32 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 시킨다 에서얻은 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 에대해반복한다.

33 2. Top Half, Bottom Halves and Deferring Work - Work Queue* Linux kernel create work or INIT_WORK Generate hardware interrupt CPU Interrupt kernel Interrupt handler work 신규등록 Hardware Request delayed work create work or INIT_WORK Some kernel loop (request work schedule repeatedly) Request delayed work work 신규등록 Worker thread Run work Worker thread Run work (delayed work 이면서, process context 에서수행 )

34 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( ) 함수호출함.

35 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 파일참조 DECLARE_WORK(name, void (*func)(void *)); or INIT_WORK(struct work_struct *work, void (*func)(void *)); <worker thread = events/0> 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

36 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 파일참조

37 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 제거

38 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 가능하며, 다른 kernel thread 혹은 interrupt handler 등에의해선점 (preemtable) 될수있다. 단, user-process 에의해선점되지는않음. (*) 사용자정의 kernel thread 는 kthreadd(parent of kernel threads) 에의해추가생성 (fork) 된다. kthread_create(my_thread) or kthread_create_list에자신을추가 kthread_run(my_thread ) macro임 int kthreadd(void *unused) { for (;;) { /* 생성할 thread 가없으면, 휴식 */ /* 있으면, 아래루틴수행 */ while (kthread_create_list is not empty) create_kthread(new_thread); } }

39 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 (my_thread) 수행! } do_exit(ret);

40 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 파일참조

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

42 다음절로넘어가기전에 * Interrupt Thread Interrupt Latency 의원인 1) long-duration ISRs 2) Disabling interrupts 3) Prioritization of interrupts 1) Interrupt 는 kernel 에게는최대 latencey 의근원이다. 이를줄이기위해 kernel thread 에거일을넘겨주고, 즉시 return. 이건기존 bottom half 와차이가없음. 차이점은, thread 에게우선순위를부여하여, preemptible thread context 에서동작하도록함. 2) Bottom half 방식은 hard, soft handler 간에 locking 이필요함. 이를단순화혹은제거하여복잡도줄여야함. <work queue 와 Interrupt thread 의차이점 > 1) Work queue 는 kernel thread 이므로, scheduler 가선택하는순간에실행될수있다. 즉, 우선순위가높은 task 가실행중이거나, 새로들어오면밀릴수있다. 이는 Real- Time OS 에서원하는방식이아님. 2) 반면에 Interrupt Thread 는우선순위를가지고움직이므로, 즉시실행될수있다. 단점은 interrupt 처리면에서는우수한반응성을보여주지만, 잦은 context switching 은전체시스템의성능저하를가져올수도있다.

43 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 를할당못받았으니 (irq thread 용 ) wait queue 에서대기하게되겠지

44 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> (*) 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 을실행함 ) 그렇지않으면, 기존 hard interrupt handler 로동작함. (*) 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)

45 2. Top Half, Bottom Halves and Deferring Work Threaded Interrupt Handler* static int irq_thread(void *data) /* IRQ 당한개씩할당되는 irq thread */ { struct irqaction *action = data; sched_setscheduler(current, SCHED_FIFO, MAX_USER_RT_PRIO/2); /* 우선순위변경 */ 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 를깨움 */

46 2. Top Half, Bottom Halves and Deferring Work Threaded Interrupt Handler * Current task X CPU do_irq() preemption external device Interrupt Line handle_irq_event() High priority wakeup thread thread_fn <irq thread> request_threaded_irq(thread_fn) 등록 (thread 생성 ) (*) work queue 와는달리, threaded interrupt handler 는높은우선순위로동작하므로, CPU 를선점할수있다.

47 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) 하는것이가능하다. (*) 위의그림에서두개의 thread 를그렸으나, 실제로는같은하나의 thread 임 (IRQ 당 1 개의 thread 만생성됨 )

48 (*) Real-Time Patch 관련참고사항 R-T Patch 주요사항 1) Spinlock 이 PI-Mutex 로교체됨. 우선순위상속지원 raw_spinlock 이 old spinlock 을대신함. 2) spinlock_t 와 rwlock_t 로보호되던 critical section 을이제는선점 (preemptible) 할수있게됨. 3) Old linux timer API 를 high-resolution timer 와 normal timer 로분리함. 4) Interrupt handler 를 preemptible thread context 에서돌리도록함. hard/soft IRQ 가모두 thread context 에서돌아감.

49 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 를의미함.

50 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 는제거된다. (1) 신규타이머등록 init_timer Timer interrupt timer_list (2) run_timer_softirq( ) <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; }; 시간대별로 Queue 관리 timer vector timer_list timer_list timer_list (3) 실행 timer_list

51 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 임

52 3. Timer(3) HZ & Jiffies* HZ: the frequency of system timer(= tick rate) 초당가능한 tick 의수 (= 주파수개념 ) CPU( 성능 ) 마다값이다름. Jiffies: the number of ticks that have occurred since the system booted. 시스템이부팅한이후로발생한 tick 의수 Seconds * HZ = jiffies 초 (seconds) 를이용하여 jiffie 값구하기 (jiffies / HZ) = seconds Jiffie 값으로부터초계산하기 예 ) unsigned long time_stamp = jiffies; /* 현재 */ unsigned long later = jiffies + 5*HZ; /* 지금부터 5 초후 */ unsigned long fraction = jiffies + HZ/10; unsigned long next_tick = jiffies + 1; /* 지금부터 1 tick 후 */

53 3. Timer(4)* 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()

54 3. Timer(5) 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 들이놀고있어, 내게차례가올경우 ) 이될경우, 주어진시간을다채우지않은상태에서도깨어날수있습니다 ^^.

55 3. Timer(6) High Resolution Timers (*) hrtimer 는기존 HZ 단위의 low-resolution timer 가 mili- 초수준의정밀도를제공하는것과는달리 nano 초단위로시간을관리하는방식이다. (*) 당연한얘기겠지만, 세밀한단위로시간 (clock) 을제공해주는장치가시스템내에존재해야한다. (*) hrtimer 의핵심은항상동일한주기로계속 timer interrupt 가발생하는것이아니라, 특정 event 가일어날시점을정확히지정하여 timer 를등록하고, 해당시점에 timer interrupt 가발생하면, 그때 event 를처리하는것이다. 따라서발생할 event 의유무및간격에따라 timer interrupt 의주기가바뀌게된다. static struct kt_data { struct hrtimer timer; ktime_t period; } *data; static enum hrtimer_restart ktfun(struct hrtimer *var) { ktime_t now = var->base->get_time(); /* */ hrtimer_forward(var, now, data->period); return HRTIMER_NORESTART; } static void exit my_exit(void) { hrtimer_cancel(&data->timer); kfree(data); } static init init my_init(void) { data = kmalloc(sizeof(*data), GFP_KERNEL); } data->period = ktime_set(1, 0); /* nano 초지정가능 */ hrtimer_init(&data->timer, CLOCK_REALTIME, HRTIMER_MODE_REL); data->timer.function = ktfun; hrtimer_start(&data->timer, data->period, HRTIMER_MODE_REL); return 0;

56 4. Synchronization(1) Concurrency(& Pseudo concurrency) 상황 * User application CPU2 CPU1 Interrupt kernel Interrupt kernel userspace kernel Interrupt handler System call Critical region shared resources - Interrupt 간 - Bottom half 간 - User process - Kernel thread - SMP 등다양한상황고려필요! lock Kernel thread Interrupt handler unlock (*) system call 은임의의시점에서발생할수있다 (Pseudo-concurrency) (*) interrupt 도임의의시점 (asynchronously) 에발생할수있으며, CPU 가두개이상일경우, 각각의 CPU 로부터동시에서로다른임의의 Interrupt 가발생할수있다 (Concurrency). Linux kernel 은 fully preemptive 한특성을가지고있으므로, 각각의경우에 kernel code 에서 shared data 를사용 (race condition) 하고있다면, 처리에신중 (locking) 을기해야할것임.

57 4. Synchronization(2) 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( ) 함수를호출하는결과초래 )

58 4. Synchronization(3) kernel preemption/1 (*) top half > bottom half > process 관련함수 save register do_irq( ) process nested interrupt save register sys_func() schedule() in sys_func() top_half bottom_half schedule( ) system call do_signal( ) schedule( ) restore register do_signal( ) restore register

59 4. Synchronization(3) kernel preemption/2 (*) 첫번째 interrupt 처리중, 보다우선순위가높은두번째 interrupt 가발생할경우, interrupt 를허용하도록설정이되어있다면아래와같은 nested interrupt 구조가가능해질수있다 ^^. save register do_irq( ) process save register top_half bottom_half nested interrupt schedule( ) hardware interrupt do_signal( ) schedule( ) restore register do_signal( ) restore register

60 4. Synchronization(4) Coding 시주의사항 /1* 1) Global data 인가? 즉, 여기말고다른곳 (thread of execution) 에서도이 data 에접근이가능한가? Thread 1 Try to lock the queue Succeeded: acquired lock Access queue Unlock the queue Thread 2 Try to lock the queue failed: waiting Waiting Waiting Succeeded: acquired lock Access queue Unlock the queue 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 상황에안전하다고확신할수있는가?

61 4. Synchronization(5) 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 를선점하지는않는다.

62 4. Synchronization(6) Coding 시주의사항 /3* Thread 1 Acquire lock A Try to acquire lock B Wait for lock B deadlock Thread 2 Acquire lock B Try to acquire lock A Wait for lock A Thread 1 Acquire lock cat Acquire lock dog Try to acquire lock fox Wait for lock fox deadlock Thread 2 Acquire lock fox Try to acquire lock dog Wait for lock dog.. Thread 1(self-deadlock) Acquire lock Acquire lock, again Wait for lock to become available

63 4. Synchronization(7) 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 Preempt_disable()/preempt_enable() Kernel preemption 을금지 / 허용 Instruction reordering 금지명령 (spinlock, irq disable, preempt_disable 등의내부를구성 )

64 4. Synchronization(8) Sync. Methods* Atomic Operations ( 수행중에는 interrupt 등에의해중단되지않음 ) atomic_t v = ATOMIC_INIT(0); atomic_set(&v, 4); /* v = 4 (atomically) */ atomic_add(2, &v); /* v = v + 2 = 6 (atomically) */ atmic_inc(&v); /* v = v + 1 = 7 (atomically) */ Interrupt context Spinlocks (resource 를사용할수있을때까지, sleep 하지않고기다림 spin) spinlock_t my_lock; spin_lock_init(&my_lock); spin_lock(&my_lock);. Critical region spin_unlock(&my_lock); Spinlocks with interrupt-disabling (resource 를사용할수있을때까지, sleep 하지않고기다림. 동시에 interrupt 를금지시킴 spinlock_t my_lock; unsigned long flags; spin_lock_init(&my_lock), flags; spin_lock_irqsave(&my_lock);. Critical region spin_unlock_irqrestore(&my_lock, flags); (*) spinlock 은 SMP 환경에서사용되도록만들어졌으나, 선점형 kernel 인 2.6 에서는 Uniprocessor 환경에서도필요하다.

65 4. Synchronization(9) Sync. Methods* Semaphores (*) 한 thread 가 lock 을얻은경우, 그다음에진입하는 Thread 는 wait queue 에서대기 (sleep) 하게된다. static DECLARE_MUTEX(mr_sem); if (down_interruptible(&mr_sem)) { /* signal received, semaphore not acquired. */ } Process context /* critical region */ up(&mr_sem); Mutexes DEFINE_MUTEX(name); /* or mutex_init(&mutex) */ mutex_lock(&mutex); /* critical region */ mutex_unlock(&mutex);

66 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);

67 4. Synchronization(11) - Sleeping & Wait Queue* (*) 앞페이지의 synchronization method 에는없었으나, wait queue 를이용하여도동일한효과를얻을수있다 ^^. (*) 앞서설명한 completion 의내부는 wait queue 로구현되어있음. wait_event ( 대기상태로빠짐 ) wait queue X task wakeup (CPU 를할당받을수있게됨 ) Critical section O run queue

68 4. Synchronization(12) - 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 Critical Region access

69 4. Synchronization(13) - 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);

70 4. Synchronization(14) Preemption Disabling & Barriers Preemption Disabling (kernel preemption 금지방법 ) preempt_disable(); /* preemption is disabled.. */ preempt_enable(); Some instructions barrier( 장벽 ) : rmb(), wmb(), mb() Some instructions (*) 최적화를위해 compile 시혹은 CPU 에서실행시, 상호 dependency 가없는 instruction 들에대해순서를바꾸게됨. (*) barrier 를사용하게되면, 이름금지시킬수있음. 즉, 사용자가작성한코드의순서대로실행하게됨. (*) 이방법은 spinlock 등 locking 기법의내부를구성하는가장기본적인방법임 ( 매우중요 ) 위의 preempt_disable( ) 의내부도 barrier 로구성되어있음.

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

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

73 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 파일참조!!!

74 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 파일참조!!!

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

76 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 파일참조!!!

77 5.2 kobjects & sysfs(4) 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 을이용하므로매우편리하다.

78 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

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

80 5.3 virtual memory & mmap(3) 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 0xC 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); } 0x User Space A <4 GB Virtual Address Space> 3GB

81 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);

82 5.3 virtual memory & mmap(5) 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 관련해서는다른서적이나문서를참고하시기바람 ^^.

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

84 6. Suspend/Resume and Wakelock(2) suspend/resume(1) Platform hooks arch/arm/mach-xxx/pm.c 파일내의 platform_suspend_ops 함수를이용하여등록함. prepare(), enter(), finish(), valid() Enter_state 함수에의해 suspend_ops 함수가호출될것임. Enter_state 함수를구동시키기위해서는 echo mem > /sys/power/state

85 6. 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

86 6. 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 제거시 )

87 6. 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);

88 6. Suspend/Resume and Wakelock(6) runtime power management <TODO> (*) I/O 장치들에대해, run-time 에 low-power state 로만들거나, wakeup 시키는것을 run-time power management 라고함, (*) PM core 에서아래의 callback 함수를정의 ( 등록 ) 한드라이버에대해작업수행한다. (*) include/linux/pm.h 파일참조 struct dev_pm_ops { int (*runtime_suspend)(struct device *dev); int (*runtime_resume)(struct device *dev); int (*runtime_idle)(struct device *dev); }; (*) 보다자세한사항은 Documentation/power/runtime_pm.tx 파일참조!

89 7. 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

90 7. Platform Device & Driver(2) - 개념 - 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, }, };

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

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

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

94 7. Platform Device & Driver(6) - 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( ) 함수가사용될수있음.

95 7. Platform Device & Driver(7) - 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 로사용되고있음.

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