kandroid_3rd_seminar_20090327_session_4_linuxandandroid_start-up_casestudy

2009 제3회 Korea Android 세미나

Linux and Android Start-upCase study : S3C6410

Naver linuxkernel26 운영자 : 박 철 ([email protected])

2009. 3. 27.

목 차

안드로이드 개요sub title 1 : 안드로이드 실행 순서sub title 2 : 임베디드 시스템 프로그램모델sub title 3 : 안드로이드 시스템의 구조

안드로이드 다운로딩 및 커널 실행과정sub title 1 : 부트로더, 커널, 안드로이드 컴파일 과정sub title 2 : 부트로더, 커널, 안드로이드 로딩 과정sub title 3 : 부트로더, 커널, 안드로이드 실행과정

안드로이드 실행과정sub title 1 : init 및 init.rc 실행 과정sub title 2 : Zygote 및 VM 실행과정sub title 3 : fork(), execve(), write() 실행과정

33rd Korea Android Seminar - www.kandroid.org

안드로이드 실행의 순서

개발환경 구축

소스 얻기

컴파일 하기

Loading 및 실행하기


#include <stdio.h>

int main()

{

printf(“Hello~ \n”);

return 0;

}

hello.c

(Source)

hello

(ELF)

arm-gcc

(Compiler)

“Text” Section

“Data” Section

“BSS” Section

“Stack” Section

Memory(DDR)CPU(S3C6410)

loading Excute

fetch

Decode

excute

Memory access

Write back

PC

Reg

Program model

runtime


임베디드 시스템의 프로그램 모델의 특징

Firm ware

작은 오두막집

Multi thread(MicroC/OS-II)

저층 빌딩

Multi process(linux)

고층 빌딩

기초공사에 대한 규격만 존재

Multi process(Android)

초고층 빌딩

전체 층이 완성에 프레임 구조 정의

내부설계 및 인터리어 까지 정의됨


Firmware Multi-Thread(RTOS)

“Data” Section

BSS

………………………………

Text TextText

Stack StackStack

scheduler

“Text” Section

“Data” Section

“BSS” Section

“Stack” Section

………

Program model – firmware/muti-thread


Multi-Process(linux)

scheduler

kernel

Library

application application application

application application application

Framework & VM

middleware & Library

kernelscheduler

Multi-Process(android)

Program model – Multi-process


안드로이드 시스템의 구조

ApplicationArea

Application frameworkApplication framework

JAVA Core libraryJAVA Core library

App1App1 App2App2 App3App3 AppnAppn

Virture File System(VFS)Virture File System(VFS)

C/C++ libraryC/C++ library

DeviceDevice

Device InterfaceDevice Interface

Inet(AF_INET)Kernel Area

Hardware

Inet(AF_INET)

Transport(TCP,UDP)

Transport(TCP,UDP)

Network(IP)Network(IP)

bionic libcbionic libc

SW InterruptSW Interrupt

System Call InterfaceSystem Call Interface

Buffer CacheBuffer Cache Network SubsystemNetwork

Subsystem

CharacterDevice DriverCharacter

Device DriverBlock

Device DriverBlock

Device DriverNetwork

Device DriverNetwork

Device Driver

Device file system

Device file system

General file system

General file system

Socket file system

Socket file system

Dalvik VMDalvik VMMiddle ware

Area


기존 커널의 확장

S3C6410용 Kernel 2.6.27 안드로이드를 지원할 수 있도록 하기 위한 커널 확장관련 패치를 제공

커널 관련한 확장들은 다음과 같다.

Alarm

Low Memory Killer

Ashmem

Kernel Debugger

Binder

Power Management

Logger

Binder

IPC의 프로세싱 오버헤드와 보안 헛점을 해결하기 위해 Binder를 채택

Power Management

모바일 디바이스가 배터리 기반에서 동작한다는 사실과 해당 배터리의용량제약이라는 상황에 대응하기 위한 구조


bionic libc

독자적으로 만들어진 linker와 libc 사용

스탠다드 glibc, uclibc를 사용하지 않음

C++ STL(Standard Templete Library) 지원하지 않음

bionic libc의 장점

라이센스: user application에서 GPL문제 회피

size: 약 200k, glibc(GNU version of libc)의 절반크기

speed: 제한된 CPU power에서 동작


Android runtime

java runtime에 동등한 레벨이다.프로세스가 동작되면서 library를 호출할 대 사용된다. 자바 어플리케이션에서 호출할 때 libc 기반의 C/C++ library를 호출할 때 runtime library를 호출dex.( Dalvik Executables (DEX)) 실행파일의 구조를 가지게 된다. 실행파일이 symbloic resolution을 통하여 함수를 가지고 있다가library를 호출한다.Android Runtime은 Dalvik VM과 Core libraries로 구성Android의 개발은 Eclipse의 ADT Plug-in을 통해서 Java로 컴파일되고 class와 resource가 Dx 컨버터를 통해서 Android App(.apk)로만들어지며 이 apk가 Dalvik VM위에서 동작하게 된다.Dalvik VM은 작은 메모리에서도 최적화 되는 Dalvik Executable (.dex) 포멧 파일을 실행한다.VM은 register-based이고, 'DX' 툴로 부터 .dex 포맷으로 변환된자바 컴파일러로 부터 컴파일 된 클래스를 구동한다.Dalvik VM은 쓰레딩과 저수준의 메모리 관리와 같은 기능을 위해 리눅스 커널에 기초한다.


Zygote(수정란)

Zygote를 통한 프로세스 관리어플리케이션을 빠르게 구동하기 위해서 미리 fork 되어 있는 프로세스이다.

시스템에서 exec() 호출을 통해 특정 애플리케이션을 실행하고자 하기 전까지는 중립적인 상태, 즉 특정 애플리케이션과 합체되지 않는 상태를 유지한다

안드로이드에서 프로세스를 생성하는 방식fork()와 execve()를 통하여 프로세스를 생성하는데 zygote를 통하여 프로세스가 생성되고 메모리를 공유하는 형식을 취는 것 같다.


일반 리눅스와 안드로이드의 메모리 사용의 차이

일반적인 내장 Linux Android

프로그램 본체

공유 라이브러리공유 파일

(.so파일, 폰트 등)

스택 스택

공유 라이브러리(libc, android_runtime

등의 .so파일)

폰트, Dalvik VM의실행 어플리케이션

프로그램 본체00008000

40000000

00008000

40000000

B0000000


프로세스의 메모리 구조

통상적인 리눅스

.so 모듈이 논리 메모리 공간의 저위 어드레스에서 고위 쪽으로할당된다.

이 할당을 실행하는 것은 ‘ld.so’ 프로그램이 일반적이다.

40000000번지부터 공유 라이브러리나 파일을 순서대로 배치.

안드로이드

공유 라이브러리가 논리 어드레스 공간의 고위 어드레스에서 저위 방향으로 확보

파일을 40000000번지부터 순방향으로, 라이브러리를B0000000번지부터 역방향으로 배치

라이브러리를 로드하는 역할을 하는 것은 ‘linker’라는 명칭의 프로그램이다.

Dalvik VM용 영역을 별도로 확보

모든 애플리케이션 프로그램을 Dalvik VM으로 동작시키기 때문에 소비하는 메모리의 양이 늘어나기 때문


안드로이드 파일시스템

/

var tmp proc sys sbin etc root

작업용파일군

bin appframe-work

libusr,fonts,media

etc,soundslost+found

저작권 관리정보로그

다운로드 결과어플리케이션 데이터

Linux로써 사용할 때의 shell등의 커맨드군

어플리케이션프로그램

Java의라이브러리군

네이티브 코드라이브러리군

system

system,dalvik,cachedrm,logs,download

data,app등

data


안드로이드 파일시스템

system, data가 추가 됨

Dalvik VM 본체

system/bin 디렉토리 있음

프로그램 resource

일반적인 리눅스 usr/bin/ 저장

안드로이드 system/ bin/ 저장

쉘(Shell) 명령어

임베디드 리눅스 : BusyBox 통해 사용 및 관리됨

안드로이드 : toolbox 통해 사용 및 관리됨


각각의 소스 컴파일

부트로더 : binary

커널 : Zimage

디바이스 드라이버 : 모듈(kernel용 목적파일) 확장자

C/C++ 라이브러리 : 동적 라이브러

Framework : XML

Application : Dex 실행파일


컴파일 과정

Boot loader

Binary

Boot loader

BinaryBoot loader

실행파일

Boot loader

실행파일

Boot loader

Source

Boot loader

Source

“ELF” file “BIN” file

부트로더 컴파일 과정

디바이스

드라이버

커널 목적파일

디바이스

드라이버

커널 목적파일

디바이스

드라이버

목적파일

디바이스

드라이버

목적파일

디바이스

드라이버

Source

디바이스

드라이버

Source

“ELF” file “ELF” file

디바이스 드라이버 컴파일 과정

미들웨어

공유라이브러리

미들웨어

공유라이브러리

미들웨어

Source

미들웨어

Source

“ELF” file

라이브러리 및 미들웨어 컴파일 과정

.ko

.so


Kernel Compile Process


안드로이드 어플리케이션 컴파일 과정


다운로딩 및 퓨징 과정

Kernel source zImage

bootloaderBootloader source

Host용 File system

fusing

Memory map

Ramdisk.img

DDR영역

NAND영역

Bootloader

System.img

Userata.img

zImage

Ramdisk.img

System.img

userdata.img

Ramdisk.img

System.img

Userdata.img

zImage

downloadNand fusing

IO 영역

Dynamic 영역

Static 영역

Nand 영역

DDR 영역

SRAM 영역

System source

Ramdisk source

Userdata source

Cupcake


안드로이드 시작

Memory map DDR영역

NAND영역

Bootloader

zImage

Ramdisk.img

System.img

Userdata.img

zImage

IO 영역

Dynamic 영역

Static 영역

Nand 영역

DDR 영역

SRAM 영역SRAM영역

Bootloader

vmliux

DDR영역

NAND영역

File system

vmliux

DDR영역

NAND영역

File system

Lib/middle

application


기존 리눅스 개발환경과 DD 및 App 실행 과정

Minicom(타겟용 터미널)

Host용 터미널

(Edit,compile)

Host Target

test.c test

sk.kosk.c

2.Cross compile

test

sk.ko

HDD RAMDISK

3.전송(Zmodem)

Memory

/dev/sk

4.insmod

5.mknod

6../test

sk.ko

test

vmlinux

1.Edit

make

Serial cableUSB or enthenet

JTAG cable

Backend


안드로이드 개발환경과 DD 과 lib 그리고 App 실행 과정

Minicom(타겟용 터미널)

Host용 터미널

(Edit,compile)

HostTarget

Serial cableUSB or enthenet

Backend

JTAG cable

sklib.c Sklib.so

sk.kosk.c

2.Cross compile

HDD RAMDISK

3.전송(Zmodem)

Memory

/dev/sk

4.insmod 5.mknod

6../test

sk.ko

Test

vmlinux

1.Edit

make

test.java Test.apk

Sklib.so

sk.ko

Test.apk

Sklib.so


S3C6410 Block Diagram

DDR

NAND

SRAM

7E00 F000

7E00 5000

7E00 4000

7F00 6000

7E00 D000

7500 0000

7F00 4000

7F00 2000

7F00 8000

7F00 5000

7F00 B000

7F00 7000

7C00 0000

7E00 6000

7C20 0000

7430 0000

7F00 1000

7E00 0000 7710 0000

0000 0000

7E00 3000

783F 0000

7880 0000

7630 0000

7600 0000

7610 0000

5000 0000

4000 0000

2800 0000

2000 0000

5000 0000

1000 0000


S3C6410 MEMORY SYSTEM BLOCK DIAGRAM

SRAM5 CF SRAM5 CF

SRAM4 CF SRAM4 CF

SRAM3 One NAND1 NAND1 SRAM3 One NAND1 NAND1

SRAM2 One NAND0 NAND0 SRAM2 One NAND0 NAND0

SRAM1 SRAM1

SRAM0 External ROM SRAM0 External ROM

Boot Loader Boot Loader Boot Loader Boot Loader Boot LoaderInternal ROM Internal ROM Internal ROM Internal ROM Internal ROM

Boot Loader Internal ROMSRAM0 External ROM One NAND0

IO 영역

DDR 영역DDR 영역

DMC0

IO 영역

DMC0

ReservedReserved

0x0000_0000

0x0800_00000x0C00_00000x1000_0000

0x1800_0000

0x2000_0000

0x2800_0000

0x3000_0000

0x3800_0000

0x4000_0000

0x5000_0000

0x7000_0000

0x7000_0000

0xFFFF_FFFF


NAND Boot Mode

Stepping stone 방식

내부 SRAM이 remapping 되어서 0번지에 존재하며

전원이 인가되었을 때stepping stone controller가DMA를제어하여 Nand의4Kbyte 영역으로 SRAM으로copy한다.

Boot InternalStepping stone(4KB)

Internal ROM

Stepping Stone

SROM 0

SROM 1

SROM 2(NAND Stepping Stone)

SROM 3

SROM 4

NAND Boot

0x0000_0000

OM[4:3] = 00


Boot Loader 실행 과정

start.SVector Table, CPU Clock, Flash, SDRAM

초기화

BeforeMain() SDRAM으로 Jump

CMain() Serial, Timer, Ethernet 초기화

Reload() GetCommand()

CMD_TBL DoTftp()

DoBootKernel()

………DoBootKernel()

KERNEL


Bootloader 기능

H/W 초기화

CPU clock, Memory timing, interrupt, UART, GPIO등을 초기화

Linux Booting

Kernel Image를 SDRAM에 저장 한 후 Kernel image 주소로 점프

Image Downloading

Kernel Image(zImage)와 file system를 SDRAM 에 download

Ethernet(bootp, tftp)를 통해서 가능

Flash 제어

Flash write, erase 기능

Flash lock, unlock 기능 등


압축푸는 과정


Kernel 초기화 과정Kernel 초기화 과정

head.S

$KERNEL_SRC/arch/arm/boot/compressed/

Head-armv.S b SYMBOL_NAME(start_kernel)

start_kernel()

$KERNEL_SRC/init/main.c

커널 초기화 시작

$KERNEL_SRC/arch/arm/kernel/


Kernel 초기화 과정 (continued)Kernel 초기화 과정 (continued)

start_kernel()1. lock_kernel()

2. setup_arch() Architecture에 의존적인 내용들(프로세서, 보드)을 설정

a. setup_processor()

b. setup_architecture()

3. paging_init() Page Table 설정, Memory Map 초기화

4. trap_init()

5. init_IRQ()

6. sched_init()


다른 부분에서 커널로의 진입을 방지

커널이 사용하게 될 예외상황(Exception*) 처리 부분 초기화

* Exception 종류 : Reset, Software Interrupt, IRQ, …

인터럽트를 나타내는 descriptor 구조체인 irq_desc[] 초기화,

irq_arch_irq() 호출 : Architecture에 의존적인 인터럽트 초기화

init_dma() 호출 : DMA를 사용하는 디바이스들 초기화

스케줄러 초기화 (주로 Bottom Half*에 대한 초기화)

Bottom Half : Kernel 2.4.X 버전부터 “tasklet”

tasklet : softirq_init() 이 담당



7. time_init()

8. console_init()

9. init_modules()

10. kmem_cache_init()

11. mem_init() 메모리 시스템 초기화, 얼마 정도의 메모리가 사용 가능한지 알려줌

12. proc_root_init()

Timer 인터럽트 초기화

콘솔(console) 초기화 (디버깅 정보 혹은 시스템 정보 출력)

커널 설정 시 “CONFIG_MODULES” 가 정의되어 있을 때 호출됨

커널의 모듈 설정과 관련된 부분 초기화 수행

전체 커널 메모리 공간에서 가지는 커널 object를 위한

cache를 연결 리스트(linked list) 형태로 유지

: “cache_chain”

/proc 이하의 메모리 내에 존재하는 파일 시스템 생성

6. sched_init()

......

proc_net = proc_mkdir(“net”, 0);

proc_mkdir(“sysvipc”, 0);

proc_sys_root = proc_mkdir(“sys”, 0);

proc_root_fs = proc_mkdir(“fs”, 0);

proc_root_driver = proc_mkdir(“driver”, 0);

proc_tty_init();

proc_device_tree_init();

proc_bus = proc_mkdir(“bus”, 0);

......

각 시스템 정보들에 대한

Entry



13. kernel_thread()

14. cpu_idle() 시스템에서 어떤 이벤트(event)가 발생하기를 무한정 기다림

커널에서 사용할 쓰레드(Thread) 생성 : “init()” 호츌

12. proc_root_init()

......

cpu_idle()

{

while(1)

{

while(!current->need_resched)

idle();

}

}

......




init()1. lock_kernel()

2. do_basic_setup()

sock_init()

다른 부분에서 커널로의 진입을 방지

start_kernel() 에서 다 처리하지 못한 시스템의

나머지 부분들을 초기화 : PCI, IrDA, PCMCIA, …

* 여기까지 수행하면 Machine에 관한 초기화는 끝!

Initrd 가 설정되어 있다면 initial RAM disk 설정

filesystem_setup()

mount_root()

mount_devfs_fs()디바이스에 대한 파일 시스템 설정

: 디바이스들에 대한 것을 파일 시스템과 같은 구조로 만들기

위해 사용 (UNIX는 모든 디바이스들을 파일로 처리)


“init” daemon (데몬) 생성“init” daemon (데몬) 생성

3. free_initmem()

4. unlock_kernel()

5. execve(“/sbin/init”, ...)

execve(“/etc/init”, ...)

execve(“/bin/init”, ...)

execve(“/bin/sh”, ...)

시스템 초기화에만 사용하고, 이후에는 사용하지 않는

메모리 영역을 해제하여 메모리를 증가시킴

시스템 콜 (System Call)

2. do_basic_setup()

만약 4개의 ‘init’ 중 아무 것도 실행이 안된다면,

6. panic(“No init found. ...”)

init daemon 생성init daemon

PID == “1”

모든 프로세스의 부모 프로세스

/etc/inittab 내용들을 수행

하위 레벨에서의 부팅 및 커널 초기화 과정 종료!!!

“init” daemon 생성 과정


Android의 시작 과정

안드로이드 Runtime library

daemon과 서비스 매니저의 시작

zygote의 시작

application의 시작


init Process

1. Initialize log system.

2. Parse /init.rc and /init.%hardware%.rc.

3. Execute early-init action in the two files parsed in step 2.

4. Device specific initialize. For example, make all device node in /dev and download firmwares.

5. Initialize property system. Actually the property system is working as a share memory. Logically it looks like a registry under Windows system.

6. Execute init action in the two files parsed in step 2.

7. Start property service.

8. Execute early-boot and boot actions in the two files parsed in step 2.

9. Execute property action in the two files parsed in step 2.

10. Enter into an indefinite loop to wait for device/property set/child process exit events. For example, if an SD card is plugined, init will receive a device add event, so it can make node for the device. Most of the important process is forked in init, so if any of them crashed, init will receive a SIGCHLD then translate it into a child process exit event, so in the loop init can handle the process exit event and execute the commands defined in *.rc(it will run command onrestart).


init.rc

console: star a shell. The source is in device/system/bin/ash.

adbd: start adb daemon. The source is in device/tools/adbd. By default is disabled.

servicemanager: start binder system. The source is in device/commands/binder.

mountd: mount all fs defined in /system/etc/mountd.conf if started, receive commands through local socket to mount any fs. The source is in device/system/bin/mountd.

debuggerd: start debug system. The source is in device/system/bin/debuggerd.

rild: start radio interface layer daemon. The source is in device/commands/rind.

zygote: start Android Java Runtime and start system server. It’s the most important service. The source is in device/servers/app.

media: start AudioFlinger, MediaPlayerService and CameraService. The source is in device/commands/mediaserver.

bootsound: play the default boot sound /system/media/audio/ui/boot.mp3. The source is in device/commands/playmp3.


init.rc

dbus: start dbus daemon, it’s only used by BlueZ. The source is in device/system/Bluetooth/dbus-daemon.

hcid: redirect hcid’s stdout and stderr to the Android logging system. The source is in device/system/bin/logwrapper. By default is disabled.

hfag: start Bluetooth handsfree audio gateway, it’s only used by BlueZ. The source is in device/system/Bluetooth/bluez-utils. By default is disabled.

hsag: start Bluetooth headset audio gateway, it’s only used by BlueZ. The source is in device/system/Bluetooth/bluez-utils. By default is disabled.

installd: start install package daemon. The source is in device/servers/installd.

flash_recovery: load /system/recovery.img. The source is in device/commands/recovery/mtdutils.


Zygote service

1. Create JAVA VM.

2. Register android native function for JAVA VM.

3. Call the main function in the JAVA class named com.android.internal.os.ZygoteInitwhose source is device/java/android/com/android/internal/os/ZygoteInit.java.

a) Load ZygoteInit class

b) Register zygote socket

c) Load preload classes(the default file is device/java/android/preloaded-classes)

d) Load preload resources

e) Call Zygote::forkSystemServer (implemented in device/dalvik/vm/InternalNative.c) to fork a new process. In the new process, call the main function in the JAVA class named com.android.server.SystemServer, whose source is in device/java/services/com/android/server.

i. Load libandroid_servers.so

ii. Call JNI native init1 function implemented in device/libs/android_servers/com_android_server_SystemServers. It only calls system_initimplemented in device/servers/system/library/system_init.cpp.


SystemServer::init2

start a new thread to start all JAVA services as follows:

Core Services:

1. Starting Power Manager

2. Creating Activity Manager

3. Starting Telephony Registry

4. Starting Package Manager

5. Set Activity Manager Service as System Process

6. Starting Context Manager

7. Starting System Context Providers

8. Starting Battery Service

9. Starting Alarm Manager

10. Starting Sensor Service

11. Starting Window Manager

12. Starting Bluetooth Service

13. Starting Mount Service


SystemServer::init2

Other services

1. Starting Status Bar Service

2. Starting Hardware Service

3. Starting NetStat Service

4. Starting Connectivity Service

5. Starting Notification Manager

6. Starting DeviceStorageMonitor Service

7. Starting Location Manager

8. Starting Search Service

9. Starting Clipboard Service

10. Starting Checkin Service

11. Starting Wallpaper Service

12. Starting Audio Service

13. Starting HeadsetObserver

14. Starting AdbSettingsObserver


SystemServer::init2

Finally SystemServer::init2 will call ActivityManagerService.systemReady to launch the first activity by senting Intent.CATEGORY_HOME intent.

There is another way to start system server, which is through a program named system_server whose source is device/servers/system/system_main.cpp. It also calls system_init to start system services. So there is a question: why does Android have two methods to start system services? My guess is that directly start system_server may have synchronous problem with zygote because system_server will call JNI to start SystemServer::init2, while at that time zygote may not start JAVA VM yet. So Android uses another method. After zynote is initialized, fork a new process to start system services.


task_struct

fs

files

fs_struct

root

pwd

dentry

dentry (dev)

dentry(sk) dentry(XXX) dentry(YYY)

d_inode d_inode d_inode

• • •

inode inode inode

i_modei_rdevi_fop

i_modei_rdevi_fop

i_modei_rdevi_fop

S_IFCHRmajor, minor&def_chr_fops

file_operations:def_chr_fops

open : chrdev_open

chrdev_open(){ f_op=chrdevs[major].fops

f->f_op->open() }

dentry_open(){ f->f_dentry = dentry }

f_dentryprivate_dataf_op

file

&def_chr_fops

f->f_op->open() : chrdev_open

dentry_open(){ f->f_op=inode->i_fop}

current->fs->root

init_special_inode(){inode -> I_fops = &def_chr_fops}

fd[0] fd[1] fd[2] fd[3] … …fd[n]

files_struct

stdinstdoutstderr

current

f

sys_mknod()

inode = dentry->d_inode;

프로세서를 관리하는 구조체


fork() 수행 과정

Libc r14_svc = swi inst. +4 SPSR_svc = CPSR CPSR[5:0] = 0b01 0011 CPSR[6] = unchanged CPSR[7] = 1 PC = 0x8

S/W인터럽트

발생

Vector Table

0x08 b vector_swi

(schedule, signal, bh_active, nested interrupt handling)

: sys_fork

ARM core

system call 번호 참조

1 sys_exit2 sys_fork3 sys_read4 sys_write5 sys_open6 sys_close………

runtime

……fork()……

fork()

……R7 <- 2Swi 0……

vector_swi()

……“번호” 추출ldreq pc, [tbl, scno, lsl #2] ……ret_with_sys_call()

sys_fork()

do_fork() ……

p = alloc_task_struct()task structure initializecopy_files()copy_fs()copy_mm()copy_sighand()copy_namespace()copy_thread()wake_up_process(p)return (p->pid)

copy_thread()

……

wake_up_process()……

do_fork()

copy_files()

……

copy_mm()

……

copy_fs()

……

copy_sighand()

……

copy_sighand()

……


fork() 수행과 자료구조

task_struct mm_struct mm_struct

copy_on_write

Memoryobject

pid = 5

mm

slg

files

pid = 6

mm

slg

files

task_struct

signal_handler table signal_handler tablesignal_struct

copy

file descriptor table file descriptor tablefiles_struct

file

opened files

signal_struct

files_struct


……“번호” 추출

ldreq pc, [tbl, scno, lsl #2]……ret_with_sys_call()

execve() 수행 과정

libc r14_svc = swi inst. +4 SPSR_svc = CPSR CPSR[5:0] = 0b01 0011 CPSR[6] = unchanged CPSR[7] = 1 PC = 0x8

S/W인터럽트

발생

Vector Table

0x08 b vector_swi


: sys_execve

ARM core



runtime

……execve()……

execve()

……R7 <- aswi 0……

vector_swi() sys_execve()

do_ execve() ……

open_exec() prepare_binprm() copy_string_kernel()copy_strings()search_binary_handler()

open_exec()

……

copy_string_kernel()

……

do_ execve()

prepare_binprm()

……

search_binary_handler()

fn()

copy_strings()

……

: load_elf_binary()

load_elf_binary()load_elf_binary()

……


execve() 수행 과정

http://lxr.fst.or.kr/source/arch/arm/kernel/calls.S?v=2.4.15-pre6-rmk2;a=arm#L22

struct linux_binfmt {

struct linux_binfmt * next;

struct module *module;

int (*load_binary)(struct linux_binprm *, struct pt_regs * regs);

int (*load_shlib)(struct file *);

int (*core_dump)(long signr, struct pt_regs * regs, struct file * file);

unsigned long min_coredump; /* minimal dump size */

};

static struct linux_binfmt elf_format = {

NULL,

THIS_MODULE,

load_elf_binary,

load_elf_library,

elf_core_dump,

ELF_EXEC_PAGESIZE

};

http://lxr.fst.or.kr/source/arch/arm/kernel/calls.S?v=2.4.15-pre6-rmk2;a=arm#L22


execve

vm_endvm_startvm_flagsvm_file…..

vm_next

map_countpgd

mmap

mm

vm_offsetvm_ops

vm_endvm_startvm_flagsvm_file…..

vm_next

vm_offsetvm_ops

vm_area

vm area

vm_area_struct

vm_area_struct

a.out (ELF format)

task_structmm_struct

e_ident…e_phnump_type

p_offsetp_vaddrp_fileszp_memszp_flags

physical header1

code

data

physical header2

……

…….

open(vm_area), close(vm_area)do_mmap(file, addr, len,

prot, flags, off)unmap()protect()nopage(), wppage()…..


Software interrupt 처리

vector_swi: ……(중략)

ldr r6, [lr, #-4]! @ get swi instruction

and r5, r6, #0x0f000000

teq r5, #0x0f000000

bne Larm700bug

...…(중략)

bic r6, r6, #0xff000000 @ mask off swi op code

eor r6, r6, #OS_NUMBER << 20 @ check OS number

Lretry:

cmp r6, #NR_SYSCALLS @ check upper syscall limit

bcs Lswi_bad_call

...…(중략)

adr ip, _sys_call_table

mov r9, sp @ hack for routines needing > 4 values

str r4, [sp, #-4]! @ new-style: (r0 = arg1, r4 = arg5)

mov lr, pc

ldr pc, [ip, r6, lsl #2] @ call sys routine


write() 수행 과정

runtime {

….write()

}

libc.awrite(){

….r7 <- 4swi 0

}

r14_svc = address of swi inst. +4 SPSR_svc = CPSR CPSR[5:0] = 0b01 0011 CPSR[6] = unchanged CPSR[7] = 1 PC = 0x8

S/W인터럽트

발생

Vector Table

0x08

vector_swi(){ ……

“번호” 추출

ldreq pc, [tbl, scno, lsl #2]

……

ret_with_sys_call()

}

b vector_swi

arch/arm/kernel/entry-common


: sys_write

sys_write(){

f->f_op->write

}

: sk_write

sk_write(){

}

ARM core




감사합니다.http://cafe.naver.com/linuxkernel26

http://cafe.naver.com/linuxkernel26

kandroid_3rd_seminar_20090327_session_4_linuxandandroid_start-up_casestudy

Documents