Modeling Aspect and Weaving 2003. 07. 15. SNU., RTOSLAB. Jiyong Park

Contents Big picture for composable operating system Modeling aspect Modeling aspect weaving Some ideas to enhance current AOP

Big picture for composable operating system

Motivation Goal Previous solution Problems Current solution To make application-specific OS easily Previous solution Divide features in modules or components Using OOP Problems Some features cannot be cleanly extracted in a module. Their codes are spread out all around the program. ex) logging, prefetch, scheduling, path-specific optimizations, … Current solution Using AOP, they are modeled as aspects. Problem 과 관련한 실제적인 문제 로깅 기능을 원하지 않는데, 내가 사용하고자 하는 모듈에서 로깅을 쓴다면 할 수 없이 로깅을 써야 하며, 로깅을 쓰면 파일 시스템을 써야 하고.. 그런 식으로 계속 써야 한다. 로깅이 분리될 수 있다면 그런 일이 없다. 더미 파일 시스템을 쓰면 되지만 깨끗한 방법은 아니다.

My Plan Where to apply AOP How Refactor existing OS: linux, eCos, uC/OS Build a new OS with AOP: too difficult How Iterative method linux 는 좋지만 C라서 UML과 잘 매핑이 될지 걱정 eCos 는 C++이지만…

How To Apply AOP With Existing OS OS source 1. Modeling UML model New aspect 2. 2. Aspect Extraction 2. Aspect+UML model 3. Weaving 모델링 과정이 얼마나 쉬울지는 모르겠다. OS가 C++같은 것이면 쉽겠지만 linux같이 C이면서 매크로를 많이 쓴 것 까지 해 줄지는 모르겠다 UML model 4. Code generator OS source

Things To Do Modeling the aspect Aspect extraction With UML UML may be extended Base: Incorporating Aspects into the UML, Mark Basch Aspect extraction No idea Automatic or semi-automatic ? Modeling the aspect weaving Using meta-model transformation Base: Automatic Model Transformations Using Extended UML Object Diagrams in Modeling Environments, Dragan Milicev WORDS 2003F paper

Modeling Aspect

Contents Limitations and weaknesses of suggested method Enhanced model Suggested method: Incorporating Aspects into the UML Particularly for designing OS Example mmap support in cramfs non-power of two memory allocator Receive live-lock problem Enhanced model Implicit aspect Join point can be in a function

Example 1 mmap support for cramfs VM system cramfs mmap: if file mapping, call cramfs.romptr or cramfs.mmap else allocate memory munmap: if file mapped area, call cramfs.munmap else deallocate memory mm_exit: romptr: mmap: munmap: read_page: read_dir: read_super: …

Example 2 HW flow control (to solve receive live-lock problem) Queue manager netif_rx: enqueue packet activate S/W irq return queue status net_rx_action: dequeue packet put to network layer if queue is recovered from congestion, wakeup device try next packet SAR device driver HW_int_handler: receive packet if queue is congested, disable interrupt and quit int_handling else try next packet wakeup: enable interrupt

Non-power of two page allocator Example 3 Non-power of two memory allocator Buddy allocator Slab allocator get_page: free_page: kmalloc: if size > 4096 then get pages from page allocator else get from slab cache kfree: free page to page allocator else put to slab cache Non-power of two page allocator get_page: new algorithm free_page: new algorithm page allocator 경우는 좀 특이하다 이전의 allocator자체가 완전 삭제되고 새로운 allocator가 사용되어야만 한다. 이전의 것을 삭제할 수 있는 능력이 aspect의 능력이어야 하는가? 아니면 단순히 make file에서 할 수 있는 것인가?

Limitations Of Suggested Method Based on AspectJ Inherited limitations from AspectJ Not suitable for modeling OS New variable, field and method cannot be added. (now implemented as introduction in AspectJ) Granularity of join point is too coarse. Sometimes, aspect feature is hard to understand than inlined feature. Point-cut designator seems to be complex and inconvenient Aspect sequence diagram is not enough. Problems with join point Limitations of AspectJ Limitations of suggested method

Limitation 1 No way to add (delete) new variables, fields and methods Inheritance in OO can solve this, if the addition is to one module. But, what if the addition should be done through multiple modules? New fields added (through modules) inode.u.cramfs.i_savedptr inode.u.cramfs.i_num_mapping mm_rblock_struct.is_mmapped mm_rblock_struct.mmapped_inode mm_rblock_struct.file_operations New functions added cramfs.cramfs_romptr cramfs.cramfs_file_mmap cramfs.cramfs_file_munmap new functions added에서 이것은 한 module (cramfs)에서만 적용되었기 때문에 문제가 없는것 처럼 보인다. 그러나 만약 이 함수들을 추가하는 것만으로 mmap지원이 다 된다면 괜찮겠지만 이 함수들을 추가하고 또 커널의 다른 부분에서 이에 대한 변경이 있어야지만 작동이 완벽해진다면 OO에서 inheritance방법으로 이것들을 추가한다고 하더라도 module화가 된 것이 아니다.

Limitation 1 (continued) Existing variable modified Power of two page allocator cache [] cache_array = {32, 64, 128, … , 2048, 4096, …} Non-power of two page allocator cache [] cache_array = {32, 64, 128, … , 2048} Incroducing in AspectJ Addition and overriding of arrtibutes and methods of other class

How to specify these two join points? Limitation 2 Granularity of join point is too coarse (function and variable) mmap() ok mapping to file ? yes fs->romptr fail no ok fs->mmap Add tblock to list alloc memory fail Add tblock to list How to specify these two join points? Make mmapped tblock Make anonymous tblock

Limitation 2 (cont’d) Cause Long (and not modular) function In OS, a function tends to be long and do everything For better performance (function call is expensive) Sometimes, it is easier to understand Kernel programmers’ habit Another example While forking new process, file descriptors of parent are be duplicated 파일시스템을 넣으면 포크할 때에 부모의 fd를 복사하는 코드가 fork코드안에 삽입되어야 한다. 이것을 현재의 aspect로 구현하면 fork가 끝난 다음에 리턴하기 전에 fd복사 코드가 들어가야 하지만 이것은 이해를 어렵게 만들 뿐더러 fork의 특별한 시멘틱 때문에 불가능 하다 fork는 2번 리턴하기 때문에 return할 때 fd를 복사하면 안된다. 즉 현재의 aspect로는 이러한 것들을 다루어주기 힘들다. 물론 UML과 관련 툴들도 이러한 시멘틱을 지원해 줄 지 의문이다.

Limitation 3 Assumption in AOP Problems Requirement Scattered and inlined feature make code hard to understand Problems Hard to track program execution from component’s view Requirement Aspect should be able to modeled independently. But, it can be viewed inlined. 일단 그 기능의 on/off 가 가능하도록 하기 위하여 따로 module 화는 되어 있어야 하지만 필요에 따라서는 그것을 한꺼번에 보게 만드는 것도 필요하다. component 쪽에서는 자신에게 적용된 aspect가 어떤 것인지, 어떤 일을 하는지 알 수 없으므로 aspect는 자신이 어떤 맥락에서 불리는지 알기 힘드므로..

Limitation 4 Point-cut designator seems to be complex and inconvenient after, before, around, cflow: makes language complex Hard to describe these when using graphical notation only ‘after’ and ‘before’ can be shown clearly Cannot add aspects to variable accesses

Limitation 5 Definition of join point is vague What do these mean? Are these necessary?

Limitation 5 One join point for a aspect Aspect sequence diagram is not sufficient to describe behavior of the aspect Event of the aspect cannot call to a component

What Is Aspect ? Aspect: cross-cutting concern Is ‘File-system’ an aspect ? No We think it as a component. It is more natural. Yes It cross-cuts several modules Process, Virtual memory, Block device, Page cache, … In OS, almost every features are aspect (each cross-cuts)  Hard to distinguish component and aspect 즉 aspect라고 규정되어지는 구조체는 없다. OS가 아닐 때에는 component 는 일정하고 거기에 aspect가 붙거나 떨어지거나 하는 식으로 이루어진다 그러나 application specific OS를 만들 때에는 component도 on/off 하여야 한다. (물론 policy 같은 것들도..) component를 on/off 하면 필연적으로 그에 의존적인 component들에 변화가 생겨야 하는데 그것을 aspect로 모델링 하자는 것이자.

Main Difference of Aspect in OS Usual program Only aspects are applied or un-applied Components are not added, removed or modified Application-specific OS Components also need to be plugged in or out A component has relationships with other components component cross-cuts components  component = aspect !!!

Enhanced Model Extend features of component (implicit aspect) Rather than introducing new concept of aspect Component can … Declare functions and fields of other components (for limitation 1) Override functions of other components add additional implementation to function after, before, around is described implicitly (for limitation 4) cflow is not implemented Override fields of other components get and set is described implicitly (for limitation 4)

Non-power of two page allocator Enhanced Model Non-power of two page allocator Previous method get_page: new algorithm free_page: before: calls(kmalloc()): if size > 4096 then get pages from page allocator and return else proceed before: calls(kfree()): free page to page allocator Slab allocator kmalloc: get from slab cache kfree: put to slab cache

Non-power of two page allocator Enhanced Model Non-power of two page allocator Modified method get_page: new algorithm free_page: Slab.kmalloc: if size > 4096 then get pages from page allocator else kmalloc() Slab.kfree: free page to page allocator else kfree() Slab allocator kmalloc: get from slab cache kfree: put to slab cache

Enhanced Model Join point can be in a function (for limitation 2) How User of the component insert join point explicitly This breaks modularity. But, this do not degrade readability much. Because it is anonymous join point. How Using dummy variable and dummy access to the variable Declaration of dummy variable and dummy access to it can be A component to provide hooking point to other components User of the component dummy variable은 target component에 의해서

file mapping support component Enhanced Model mmap() ok mapping to file ? yes fs->romptr fail no ok fs->mmap access dummy2 alloc memory fail access dummy Add tblock to list Add tblock to list declare mmap.dummy declare mmap.dummy2 file mapping support component override dummy: make anonymous tblock override dummy: make file mapped tblock

Future Works Get meta-model of this model Have to learn about UML notations Model the aspect weaving process Based on the meta-model Expected to take 2 ~ 3 days to design

Future Works Find more problems with current AOP Devise enhanced AOP model suitable for OS Add features to linux without and with AspectC Features Rate Monotonic scheduling Priority Ceiling Protocol With help of Michael How about submit to AOSD 2004? Full draft until October 22th