linux 강의자료 ed10
TRANSCRIPT
1
일반
구조
. 다수 의 User process (실행 Program 주체) 와 Kernel process 의 동작에 의한 Multi user Real time Operating 시스템 이다
(통상 Embedded 시스템 에서는 Root User 로 만 운영이 된다)
. User Process 에서 Kernel Process 로 진입을 TRAP 이라고 하며, 세가지 조건 에 의하여 발생된다
. Device 는 세가지 종류로 구분되며, 이를 구동하는 소프트웨어를 Device Driver 하고 칭한다
. 통상 Embedded 시스템 의 File System 은 Flash 저장장치 를 이용한다
User
Process A
User Process C
User Process B
Kernel
(Process, Memory, Device, File System, Network,,)
Kernel Process
Character Device
Block Device
Network Device
Root File System
User File System
Bin Sbin Usr Lib Dev Etc Tmp Mnt Proc Opt
x.so y.so
C.ELF Main()
2
일반
TRAP
. User Process 실행 상태에서 Kernel Process 실행상태 로 전이 되는 것을 TRAP 이라 하며, 아래 세가지 조건에 의한다
(1) User Process 의 system call 명령에 의하여
(2) Signal 발생 에 의하여, 이를 Common Trap 이라 한다
(3) Device 의 Interrupt 발생 시
. 개념도
TRAP
User Process
Device
SIGNAL
system call
INTR Common
Kernel Process
User Process
Signal Handler
callback
Kernel Process
UP 가 KP 에게 Signal 처리방법 사전통지 (1) 특정 Signal Handler 등록 (2) 특정 Signal 무시
< Signal 종류 > SIGHUP : 표준 입출력 장치 미 반응 SIGINT : CTRL+C SIGSEGV : Segment Violation SIGQUIT : SIGILL : Illegal Instruction SIGUSR1 : SIGUSR2 : SIGKILL : Kernel 이 프로세스 강제 죽임 SIGSTOP : By CTRL+Z SIGPIPE : fd 없는데 send 시
3
Image 제작
Image 형상물
. Target System 에서 운영되는 Software (Image) 형상물 은 아래와 같이 4가지로 분류 할 수 있다
(1) Boot Loader
(2) Kernel
(3) Root File System
(4) User Process Application (Executable Object) & Shared Object
. Embedded Target 의 일반적인 Image 제작과정
Kernel Source
Root File System Source
vmlinuz
Executable & Shared Object
Source
Romized FS
vmlinux (ELF)
RFS
ELF
make
make
make
mksquash mkcramfs
gzip
통합
Image
Tool
별도 File System In Target
RFS /usr/ 에 추가(방법1)
별도 File System 에 설치 (방법2)
menuconfig
Tool Chain
4
Image 제작
참고, Android Firmware
. 안드로이드 FW 는 3가지 로 분류된다
(1) BootLoader.img
(2) boot.img : Kernel, Ramsidk.img 를 포함
(3) system.img ; User space Applications and Libraries
* ramdisk.img : Root File System 을 Ramdisk 파일 시스템 으로 romize 시킨 파일이다
. System.img
(1) out/target/product/modelx/system 및 /persist 디렉토리 밑의 파일들
(2) RAM disk image 일 것이다
(3) 초창기에는 yaffs 를 사용하였으나 최근에는 ext4 file system 을 사용한다
(4) Target system 에서 mount 되어져 사용된다 (/system)
Linux Tool
(1) ext2simg : convert file format from ext4 to sparse
(2) simg2img : convert file format from sparse to 실제사용
(1) ./ext2simg system.img.ext4 system.imgs : 서버에서 (2) ./simg2img system.imgs system.img.raw : (3) mkdir test : (4) mount -t ext4 -o loop system.img.raw test/ : test 폴더에 system.img.raw 를 mount 합니다
5
Image 제작
ELF (Executable or Linking Format)
. Compile 과정을 통하여 만들어 지는 실행 가능한 혹은 동적 Link 가능한 Object 을 의미한다
. 4가지 Object 종류 를 지닌다
(1) REL ; 재배치 가능한 Executable Object
(2) EXEC ; 실행가능 한 Executable Object, Main() 이 존재 하여야 한다
(3) DYN ; 동적 Link 가능한 Shared Object , 확장 자 를 통상 .so 를 사용한다
(4) CORE ; Core Dump 용 Object
ELF 구성
구역 Description 비고
ELF Header Object 종류 (type) 및 전체 구성정보 를 지닌다 readelf –h name
Program Header Program [] 에 대한 구성정보 를 지닌다 readelf –l name
Program [] 9가지 세부 Type 이 있다 PT_LOAD 1 로드된 프로그램 세그먼트 PT_DYNAMIC 2 동적 링크 정보 PT_INTERP 3 프로그램 인터프리터 PT_NOTE 4 추가 정보 PT_SHLIB 5 공유 라이브러리(?) 정보 PT_PHDR 6 프로그램 헤더 테이블 자신 PT_TLS 7 스레드 지역 저장소 PT_GNU_EH_FRAME 0x6474e550 GNU .eh_frame_hdr 세그먼트 PT_GNU_STACK 0x6474e551 스택 실행 가능성(?)
Section Header Section [] 에 대한 구성정보 를 지닌다 readelf –S name
Section [] 21 가지 세부 Type 이 있다 . bss, data, rodata, text . dynamic, dynstr, dynsym . debug, symtab, strtab, shstrtab . comment, init, fini, got, interp, line, note, plt, rel, hash
readelf –s symtab
6
Image 제작
LINKING
. 정의 : 실행 가능한 (Executable) Object 에 Linking 가능 한 Object 을 연결하는 방법 이다
. Link 방법
(1) Static 방법 : Compile 시에 연결관계 가 확정된다
(2) Dynamic 방법 : 실행시기 에 연결이 되어지며, Dynamic Link 와 Dynamic Load 두가 지 방법으로 분류 된다
Shared Object
. Dynamic Linking 가능한 Object 으로 정의 한다.
. Share Object 은 User Process 간 Shared 되어지는 실제 활용으로 Shared 라는 명칭을 사용한다
Executable Object
Shared Object
Dynamic Link
ld.so
Executable Object
Archive Library
Static Link
Executable Object
Shared Object
Dynamic Load
ld.so dl.so
DL API
User Process A
Kernel Process
User Process B
User Process C
Shared Object A
< Shared Object 실행 시, 해당경로 찾는 방법 > 아래 세가지 방법 중 한가지를 사용한다 (1) Compile 시에 환경변수 (LD_LIBRARY_PATH) 로 지정 (2) etc/ld.so.conf 에 지정 (3) ldconfig 시스템 command 를 통하여 Update (ldconfig –n /opt/mylib/ ) < System Command > ldconfig : ld.so 에게 run time binding 에 대한 caching 정보 update ldd : 실행 Prog. 에 대한 공유 Lib. 의존성 파악
7
Image 제작
실행 Program Compile 방법
. Compile 과정을 통하여 Library, Shared Object, Static Link 실행 이미지, Dynamic Link 실행 이미지 제작 방법 이다
(1) Archive Library
(2) 실행 Program by Static Link
(3) Shared Object
(4) 실행 Program by Dynamic Link
test.c libtest.a test.o gcc –c test.c ar Cr libtest.a test.o
test.c libtest.so test.o gcc –fPIC -c test.c gcc –shared –fPIC –o libtest.so test.o
main.c 실행Prog A
gcc –static –o A main.c –L -ltest
main.c 실행Prog B
gcc –rdynamic –o B main.c –L –ltest gcc –rdynamic –o B main.c –L –ltest –ldl (for Dynamic Load)
Static Link
Dynamic
8
프로세스
Process 란
. 특정 프로그램을 실행하고 있는 주체자
. 독립적인 자원 (메모리, 표준입출력, 파일) 에 지니는 주체자
. 소유주 의 소유물로 관리되며, 프로세스 가 접근 하려는 파일의 속성은 소유주의 영향을 받는다
구분 관리정보
소유주 정보
UID / EUID GID / EGID
프로세스 정보
PID PPID PGID SID
소유주 (Owner)
사용자 (User)
Process
User uid gid ==== === === root 0 0 Kim 10 10 Park 20 20 Kwon 30 10
file
<Access 권한> 3 집단 : Owner, Group, Others chmod : 777, read/write/execute chown : kim Park chgrp : 10 20
chmod : setuid, setgid 도 가능
프로그램을 실행하면 프로세스가 생성되며, 실행된 프로세스의 소유주가 된다
파일을 실제 access 하는 주체는 프로세스 이며 EUID , EGID 가 동일하여야 Access 가능
실행 Program
실행 Program 은 특정 프로세스 에 구속되지 않는다
운영 중 에 소유주 정보를 변경 가능한 System call 이 있다 : setuid, seteuid, setgid, setegid
9
프로세스
시스템 기동과정
. Boot Loader Kernel Root File System Kernel 및 User Process 순으로 기동이 된다.
. 프로세스는 Root User 소유주 로 Shell Script 에 의하여 통상 아래 과정으로 살아난다
. Shell Script 파일 호출순서 : inittab rcS S0 ~ S9 rc.user
< Shell Script 일반 > 1) 특정한 확장자 를 지니지 않고, 실행 시 “.화일네임” 으로 하여야 한다 2) bin/sh 에 의하여 수행 되며, 이것의 수행도 하나의 프로세스로 진행된다 3) Script 내에서 다른 script 를 수행시킬 수 있으며, 이때도 “bin/sh script_name “ 으로 프로세스가 생성된다 4) Script 문장 (1) Pre Processor : #!bin/sh (2) System Command 및 User Process Application (실행 Program – Executable Object ) Binary 에 대한 각 실행 마다 자식 프로세스가 생성된다
(3) 조건 절 문 : if-fi, if-else-fi, selection-do-done
Wrapper (0)
Root User
Init (1)
Kthread (2)
Kernel ProcS
Shell rcS
Daemon ProcS
Shell rc.user
User ProcS
Kernel Process
User Process
User Process
Application
Security 목적으로 자원 및 장치의 관리를 Kernel 계층의 Process 만이 하도록 사용자 Process 와 분리한다
< Daemon Process > Background Process 1) 고아 Process 이다 PID always 1
2) 표준 입출력, 에러를 지니지 않는다 3) Terminal 을 지니지 않는다
10
프로세스
프로세스 생성방법
1) execl (execv)
. 새로운 프로세스를 실행 시키지만, 원본 프로세스의 이미지를 덮어쓴다 (호출하는 프로세스를 새로운 프로세스로 변경시키는 목적) . 즉, 프로세스의 개수도 그전과 동일하며, PID 번호도 변경되지 않는다 2) fork . 다중 프로세스 생성기법이다 (Parent 와 Child 관계가 fork 처럼 생겨서 붙여진 이름) . 원본 (부모) 프로세스의 복사본(자식) 을 만드는 것이다-부모와 자식간에는 동일 그룹이 됨. . 부모 및 자식 프로세스의 실행코드를 지니며, 자식 프로세스의 실행코드에 exec 를 지녀, 진정한 다중 프로세스 생성 및 실행이 가능하다 (대부분의 적용방법)
Shell 처리시 프로세스 생성처리 예
Bash Process
telnet login ls
Process execl exit
fork()
. 사용자 가 접속하면 bash 프로세스가 생긴다 . 사용자 가 ls 명령어를 입력
자식 Process
. 자식 Process 를 새로운 독립적인 프로세스 화 . 실제 ls 를 수행한다
. Exit 가 되면서
. 자식 Process 도 종료
< fork 사용법 > pid = fork() ; 0 : 자식 Process 실행 명령어 > 0 : 부모 Process 실행 명령어 -1 : Error
11
프로세스
Process Management
. User Application Process 는 다수의 Thread 로 구성된다.
. 특정한 프로세스 내에서 각 독립된 실행주체 의 객체를 Thread 라고 하며, Scheduling 대상이 되며
아래와 같은 구성관계 및 관리정보를 지닌다.
User Process A
Thread A
Thread B
Thread C
stack stack stack
개별정보 . Thread ID . Scheduling Policy / Priority . Signal Mask . TCB (Set of register, stack pointer) . Stack for local variables, return address . return value (errno)
공유 Memory
공유자원정보
표준 입출력
. Process Instructions
. Most data
. Open Files
. Signals signal handlers
. Current working directory
. User & Group ID
프로세스 에 속한 모든 Thread 들은 표준 입출력 장치를 공용 사용하며 동일한 메모리 공간을 사용한다
12
프로세스
Thread
. 프로세스 의 자원을 공유하며, 독립적 이고 병행적인 실행흐름을 갖는 프로그램 실행단위 이다
. User Process Application 에서는 pthread 라는 system call 을 이용하여 thread 생성 및 Sync 를 적용한다
. Scheduling Policy 는 세 가지 를 지닌다.
(1) Round Robin : 선점형 실시간 방식 with Round robin 기반
(2) FIFO : 선점형 실시간 방식 with FIFO 기반.
(3) OTHERS : 비 선점형 방식 (통상 이것을 사용)
* Others 인 경우 Static Priority 는 안되며, 운영 중에 setpriority() 라는 system call 을 통하여 priority 는 변경이 가능하나,
엄밀히 말하면 이는 nice 값에 대한 조정이다.
. Thread 간 Sync (pthread system call)
(1) Mutex : Thread 간 자원에 대한 race condition 방지
(2) Sync : Conditional Variable 을 이용한 Signal 을 사용한다 (1:1 개념, cond_signal)
(3) Message : Conditional Variable 을 이용하여 Message 수 발신 가능하다, (1:n 개념, cond_braodcast)
. 통상 User Process Application (Executable Object) 에서는 아래와 같은 모습으로 Thread 가 생성된다
User Process Application Main()
Thread-1
Thread-2
Thread-n
13
프로세스
IPC (Inter Process Communication)
. 프로세스 는 독립적인 자원 (파일, 메모리,,) 을 지니는 주체 임으로 프로세스 간에 통신은 특정한 4가지 방법에 의한다
(1) Nameless PIPE 방법 : PIPE 를 이용하여 동일 프로세스 그룹간에 이용
(2) Named PIPE 방법 : mkfifo 를 이용하여 프로세스 간 공유화일 이용
(3) Socket (Unix Domain Socket, AF_UNIX) 을 매개체로 이용하는 방법
(4) System Call 을 이용하는 방법 : shmget, msgget
(2) Named PIPE 방법
. 단 방향 만 가능하다
. mkfifo 는 system call 이 아닌, Shared Lib 가 제공하는 function 이다
(3) UDS Socket 방법
. 양 방향 통신 가능 하다
. IF_INET 과 차이점 : AF_UNIX domain 사용, Port 가 아닌 파일지정, socket_addr 구조체 틀림
Process A FIFO file
Process B
mkfifo (“/tmp/ipcfile.txt”) open (“/tmp/ipcfile.txt”) write()
open (“/tmp/ipcfile.txt”) read()
Process A file
Process B
socket connect read / write
UDS Socket (Client)
UDS Socket
(Server)
Socket bind / listen / accept read / write
14
Memory
Linux 메모리 특징
. 메모리 사용 주체들의 메모리 접근은 Virtual Memory 주소로 관리된다 (할당 및 Access)
. 리눅스는 실행 화일 (User process) 을 실제로 물리적 메모리에서 가져오는 대신에,단지 프로세의 가상 메모리와 연결만 시킨다
. Virtual Memory 에 대한 관리는 Kernel 이 담당하고, Max Size 는 1GB 이며, 1GB 초과 시 에는 Low, High Memory 로 구분한다
. Virtual Memory 는 Page 로 관리되며, Page size 는 커널 별 로 틀리나 주로 4KB 가 사용된다
. 운영중 Memory 관리자는 Kernel 이 주인 이며, MMU 장치를 통하여 Physical 로 Mapping 된다
. Physical Memory 는 CPU 가 지니는 모든 Memory Region 이 해당된다
. MMU (Memory Management Unit) 는 Cache 에 대한 관리도 포함 한다.
. Virtual Memory 는 Segment 로 관리되며, Compile 시 Mapping 되는 주소는 Virtual 주소 기준이다
속성별로 몇 가지 Segment 로 나뉘어 진다.
메모리 사용주체
Virtual Memory By Kernel
Physical Memory By CPU Arch.
MMU
L1 L2 Cache
Main Memory CPU Register I/O (ISA) Region I/O (PCI) Region
Virtual Segment 속성 Virtual 주소 Physical Mapping 방법
Kuser TLB, Cacheable 0x0000 0000 TLB (Translator Block) 에 의하여 결정
Kseg3 TLB, Cacheable 0xD000 0000 TLB 에 의하여 결정
Kseg2 TLB, Cacheable 0xC000 0000 TLB 에 의하여 결정
Kseg1 No cacheable 0xB000 0000 Low memory 반드시 사용
Kseg0 Cacheable 0xA000 0000 Low memory 반드시 사용
15
Memory
메모리 사용 주체자
. 크게 분류하면, UP (User Process) 와 KP (Kernel Process) 사용주체로 구분된다.
. UP 는 각 UP 별로 개별적인 메모리 공간을 지니고 있다.
. 할당/접근 방법은 크게 아래와 같이 분류된다
(1) 커널에게 지정된 Main Memory (DRAM) 에 대한 할당 및 접근 요청
(2) Register 및 I/O Memory 영역에 대한 접근요청 - Memory Mapping (mmap/ioremap)
User Process A
User Process B
User Process C
User-1 Memory
User-3 Memory
User-2 Memory
Virtual Memory
Kernel Process
Kernel Memory
kmalloc vmalloc ioremap
malloc mmap
16
Memory
Memory Mapping
. Kernel 메모리 관리자 에게, 할당 된 Main Memory 영역 이외에 Register 혹은 IO 영역을 메모리 사용 주체자 가 접근을 요청 하는 것이다
. 접근 하고자 하는 Physical 메모리에 대한 Virtual Memory 주소로 Mapping 을 의미한다. . mmap 과 ioremap 이 사용되며, 동일한 개념이나, mmap 은 system call 의 일종이다. (1) mmap : memory mapping, UP 내에서 사용 (2) ioremap : I/O re mapping, KP 내에서 사용 . mmap 은 통상 User Mode Device Driver 형태에서 사용되며, User Process Application 에서 메모리 이외 영역을 직접 Access 하고자 함이다 주로 아래 유형을 Mapping 한다 (1) Device Register (2) Device (HW 장치) 가 사용하는 Main Memory 영역 (BRCM Heap - TS Buffer, Decoder Buffer, GFX Surface, Display Buffer) * virtual_address = mmap (*start, size, prot_mode, flags, fd, offset) * mmap 을 위하여 고정된 "mem" device 장치가 커널에 존재한다. . ioremap 은 Device Driver 내에서 만 사용되며 (Kernel Privileged API) mmap 이 사용하는 유형 포함하여 I/O (ISA, PCI) 영역에 대한 mapping 을 주로 한다. . ioremap 에 의하여 접근이 허용된 메모리 region 에 대하여는 특정한 API 를 통하여 Kernel Memory 에 copy 가 가능하며, 아래 그림은 적용 개념도 이다.
User Process A
User Memory
malloc
Kernel Process
Kernel Memory
PCI I/O region
PCI Controller
kmalloc
copy_to_user copy_from_user
memcpy_fromio memcpy_toio
ioremap
17
Memory
사용정보
. /proc/추상화를 통하여 메모리 사용 정보를 알 수 있다
proc/iomem Physical 메모리 구성정보
proc/meminfo Total, Free, Used Status
proc/vmstat Page 종류별 Status
proc/pid/map 프로세스 별 메모리 Map
proc/pid/status 프로세스 별 용도별 , VmSize, VmData /VmRSS / VmStack
이 것을 통하여 어느 Process 에서 고갈을 유발하는지 알 수 있다
. 사용량 정보 : free 혹은 /proc/meminfo 를 통하여 알 수 있다
Total : Used + Free + (Buffer/Cached) Page 들 의 합이다, 이론적으로 Physical – Device Heap size 이어야 한다
Used : Used Page 들의 합 (used_page * 4KB) , 할당 (malloc) 만 으로는 Used 로 되지 않고 실제 사용되어야 Used 로 된다
Free : Free Page 들의 합 (free_page * 4KB)
Cached : File system 을 위한 cached 영역으로 사용되는 량
Buffer : Block Device 를 위한 bufer 영역으로 사용되는 량
Shared : 프로세스 간 공유 메모리 량
. Page 종류별 세부 Status (vmstat)
구분 해당 Page Page 용도
Free Free
Used Mapped Anonymous Slab_reclaimable Slab_unclaimable Vmalloc_used Page_table
디스크의 파일과 Mapping 되는 개념, 즉 실행 Process 의 Code 및 Data 로 사용된 량 Mapped 가 아닌 나머지 영역, 즉 동적 (malloc) 으로 할당된 영역 Kernel 프로세스 의 Kmalloc 영역 , 회수가능 Kernel 프로세스 의 Kmalloc 영역 , 회수불가능 Kernel 프로세스 의 Vmalloc 영역 Page 를 관리하는 Table
Buffer / Cached File
Block device 를 위한 Buffer 및 파일 시스템을 위한 Cache 용도
18
Device Driver
일반
(1) Linux 운영체제에서 특정한 HW 장치를 구동하는 SW 모듈이며, 아래와 같은 일반적인 모습을 지닌다
(2) 장치파일 (dev/xxxx) 은 User Process 에게 사용 가능한 장치들에 대한 List 를 알리는 것으로서 (Kernel 에서 사전에 만든다), Linux 의 Kernel 과 UP 간 추상화 개념의 (Dev,Proc,Sys) 파일 이다. (3) Device Node (장치 List) -. DD 모듈이 Initialize 되는 (Module_Init) 중에 커널에 의하여 등록 (mknode) 되어진다. -. Character Device 들은 동일한 기능을 가졌다 하더라도 실제의 세부별 (Minor) 로 등록된다 (COM1~4) -. Block Device 들은 Device Node 가 파티션 단위로 등록된다. 예. HDD 내에 파티션이 3개 있다면 : sda1 ~ sda3 (Major Number 는 동일) 예. Flash 내에 파티션이 9개 있다면 : mtd1 ~ mtd9 (Major Number 는 동일) -. Network Device 들은 Device Node 에 등록이 안 된다 (socket 이라는 추상화 를 사용한다) (4) Device Driver 모듈 -. Major Number 단위로 존재 한다. : open ("ttyS0") 를 하였다면, 해당되는 Device Driver 모듈은 4번을 지닌 것으로 연결된다. -. 예를 들어서 COM port 가 3개 있는 HW 라면, Device Node 에는 동일한 Major Number 를 가진 3개가 등록 될 것이며, Driver 모듈은 하나만 존재한다.
User Process
Kernel Process
Device Node
장치화일 (dev/ttyS0)
Device Driver A
Device Driver B
mknode
구분 : Char / Block Node Name : “ttyS0” Major Number : 4 Minor Number : 0
Device B
Device A
ISR
< Driver Info > Name Major Number Functions
system call (장치화일) - open, read, write, ioctl
INTR
19
Device Driver
Device Driver 구분
. 아래와 같이 세가지 구분 방법으로 특징 화 할 수 있다.
. Device 를 사용하기 위하여, 일반적으로 아래와 같은 주체 별 기능을 담당한다
구분 종류 비고
내장 형태별 Embedded Module . Kernel Image (Binary) 에 포함
Insert Module . “.ko” 형태로 root file system 에 존재하며, 시스템 기동 과정 중 Init 프로세스에 의하거나 혹은 운영 중 User Process 에 의하여 insmod 되어 사용되어 진다
장치 종류별 Character . Data r/w 특징 이 character 적 개념 . Block 과 Network device 가 아니라면 Character Device 이다
Block . Data r/w 특징 이 block 적 개념, HDD 및 Flash Device
Network . TCP/IP 를 사용하는 통신장치
Driver Code 위치 User Mode . HW 장치 사용이 일반 User Process 에서 진행 . mmap system call 을 통하여 커널 에 access 하려는 주소에 대하여 사전허가를 득한다 . User Mode 일 지라도 base 한 부분은 (예. ISR 처리 부) Kernel 모드로 사용
Kernel Mode . 정석대로 모든 HW 장치는 Kernel Process 내의 driver 모듈에서 처리
장치 종류 At Device Driver Module_Init() At System At User Application
Character Device register_chrdev (“pod”) handle = open (“/dev/pod”) read (hanlde) write (handle)
Block Device device_add register_blkdev (“sd”)
fdisk “/dev/sda” mkfs “/dev/sda1” mount /dev/sda1” “/mnt/hd1”
fd = open (“/mnt/hd1/aaa”) read (fd)
Network Device dev = alloc_net_dev (“eth%d”) register_net_dev (dev)
ifconfig eth0 socket (IP)
20
Device Driver
Block Device 특징
. Partition 단위로 장치 화일 (device node) 이 관리 된다 (예. /dev/mtd1 ~ /dev/mtd5)
. Partition 은 File system 을 통하여 사용 되거나 Raw block 인 경우 file system 없이 사용된다
(Raw block 인 경우 Open 만으로 사용 가능, 주로 embedded target 에서 시스템이 사용하는 flash memory영역)
. File system 으로 관리되는 파티션은 Mount 행위를 통하여 사용자 와 Block Device 간 사용 가능한 추상화 가 이루어 진다
사용자는 Mount 되어진 경로명을 사용한다
. 4개의 파티션을 지니는 HDD 의 사용개념
. Raw Block 사용개념
User Application
Kernel Block Device
Kernel File System
sda1
sda2
sda3
sda4
HW장치 (ATA)
Device Driver (SD)
< Mount Name > /mnt/hd1 /mnt/hd2 /mnt/hd3 /mnt/hd4
< 장치화일 명> /dev/sda1 /dev/sda2 /dev/sda3 /dev/sda4
1st HDD (sda) 2nd HDD (sdb) mount
< 사용순서> fdisk “/dev/sda” mkfs “/dev/sda1” mount /dev/sda1” “/mnt/hd1” open (“/mnt/hd1/aaa”)
User Application
Kernel Block Device mtd1
HW장치
Device Driver (mtd)
< 장치화일 명 > /dev/mtd1
< 사용순서> open (“/dev/mtd1/aaa”)
21
Device Driver
Network Device 특징
. Kernel 이 제공하는 TCP/IP 를 사용하는 종단 장치 들 이다
. 장치 화일 (Device Node) 에 등록이 되지 않는다
이는 User Process 가 Kernel Process 에게 직접적인 장치사용이 아닌 Socket 이라는 가상파일 로 사용이 되기 때문이다.
. 특정 Device Driver 와 의 연결은 IP 주소를 통하여 연결이 되어진다
. ifconfig 는 System Software 가 담당한다
User Application
Kernel (Socket)
Kernel (TCP/IP)
Dest. IP
Network Interface (wifi0)
Network Interface
(eth0)
Device Driver
(Ethernet)
Device Driver (WiFi)
HW장치
HW장치
socket send recv
ifconfig Interface Name ifconfig MAC Address ifconfig IP Address ifconfig up / down
192.168.0.x
10.240.1.x
22
Device Driver
Network Device 특징
. 초기화 과정 및 운영 중 Packet 송수신 절차
Parameter description
Name Interface Name
Flag RUNNING, NOARP, EBRIDGE BONDING, 801_1Q_VLAN
mtu MTU Size
dev_addr MAC 주소
irq base_addr type
HW정보 HW정보 Ethernet/PPV
buffer_tx buffer_rx
TX 용 SKB 의 start,end RX 용 SKB 의 start,end
Functions
open,stop hard_start_xmit tx_timeout set_mac_address set_multicast_list do_ioctl
Device Driver Module_Init
Kernel
Network Interface (NIF)
net_dev
SK Buffer
Device Driver
alloc_net_dev ether_setup Register_netdev
생성
By ether_setup
hard_start_xmit // for send netif_rx // for recv
IP Layer
dev_alloc_skb netif_start_queue netif_stop_queue netif_wait_queue
NIF 가 자체적으로 정보를 관리하거나, ether_setup 과정 중 DD 가 일부 채운다 (MAC주소,HW정보,Functions)
23
Device Driver
Interrupt
. HW 장치가 해당 Device Driver 에게 Attention 을 요청 하는 것이다
(Data 의 수신 ready, Data 의 송신완료, 요청한 Command 에 대한 완료)
. Trap 의 일종으로 User Process 에서 커널 프로세스 로 실행이 전이 된다
. proc/interrupt 을 통하여 상세정보 관리된다
HW장치 Exception
Vector
INTR Handler
Device Driver A
Driver A ISR Function
Driver A Thread
HW장치
request_irq enable_irq INTR
call_ISR
wakeup action
Buffer < ISR 일반적인 특징 > 1) 가능한 짧은 Syntax 를 지녀야 한다 2) Thread 주 업무 처리를 위하여 wakeup 시킨다 3) 진입시 INTR 은 disable 처리하고 종료시 INTR enable 처리 (clear INT) 4) Kernel privilege API 중 사용금지 사항 존재
24
File System
구조
. Kernel 내부에 존재하는 파일 시스템 으로 Block Device 에 대한 사용자 Interface 이다
. 일반적으로 HDD 인 경우에는 EXT4 파일 시스템이 사용 되지만,
Embedded Target 에서는 Flash Memory 를 사용하는 특징으로 인하여 다양한 File system 이 존재하며
아래와 같은 구조적인 모습을 지닌다
. 설명을 돕고자 파일 시스템을 사용하지 않는 Raw Block 을 사용하는 Application 인 경우도 그림에 추가하였다
SCSI
ATA
SATA
EXT4
HDD
SQUAHFS CRAMFS
YAFFS JFFS2FS
UBIFS EXT4
MTD (Memory Technology Device)
DDL (Device Dependence Layer)
UBI
NAND Flash
MTD
DDL
NOR Flash
JFFS
Kernel File Manager
Raw Block Applicatio
n
25
File System
File System 별 특징
File System 특징
SQUAHFS . Root FS 에 사용되며, Compressed Romize 되어 read only 로 사용된다 . 최대 1MB Block size
CRAMFS . Root FS 에 사용되며, Compressed Romize 되어 read only 로 사용된다
JFFS2 . NOR 용 JFFS 를 계승 하였으며, NAND 용 이다
YAFFS2 . Yet Another Flash File System . JFFS2 대비 ram overhead 가 감소, 성능이 향상 (10%) . Default Block Size = 512 byte
UBIFS . Unsorted Blocked Image Flash File System . NOKIA (2007 년), 범용 목적 . UBI layer에서 Bad block 관리 및 wear leveling 을 담당 . 압축을 지원함 (YAFFS2 는 압축 미 지원) . Default Block size = 4096 byte
26
File System
File System 내부 자료구조
. Inode 정보는 파일 당 하나씩 존재하며, 실제 Physical 한 Block 위치를 지정하는 정보를 지닌다
. Block 의 용도는 Inode 와 Data Block 으로 나누어 지며, Data Block 의 내용물 분류는 4가지 로 나뉜다
< File System 속성 정보 > Mount Count Maximum Mount Count Block Size 4096 Fragment Size 4096 Inode Size 256 Block Per Group 32768 Inode Blocks Per Group 209 Inode Per Group 3344
<INODE 정보내용 > . The type of file 정규파일, 디렉터리, 문서 장치 파일, 블록 장치 파일, 링크파일, 파이프, 소켓 . The access mode, UID and GID number for file owner . 파일 Size . 시간 정보 : 파일 생성,갱신,Access 시, Inode 변경 시 . 사용 되는 Data Block 위치, 12개의 Direct Pointer - 작은 파일 Size 용, 최대 48KB . 사용 되는 Data Block 위치, 3개의 Indirect Pointer (Single, Double, Triple) - 큰 Size 의 파일을 위함
Group 1
Data Block (1~32768)
INODE Block (1~209)
< Data Block 내용물 종류 > (1) Super Block 용 (2) Directory 정보용 (3) 원본파일 Data 용 (4) 원본파일 Pointer 용 (for symbolic link) < Directory 정보내용> . File Name, Inode Number
INODE 1
Data Block x
INODE 2
INODE 3344
Direct Pointer 방식
Data Block x
Indirect Pointer 방식
.
.
.
File System
< System Command > fdisk : Partition mkfs : Make File System mount : Mount fsck : FS Check repair : FS Repair tune2fs : FS 정보확인 및 속성변경
27
File System
NAND Flash 모습
. CPU 와 Interface 는 I/O Mapped 모드를 사용한다 (NOR Flash 는 Memory Mapped 사용)
. NAND controller 는 Package 에 내장 되어 있거나 (eMMC, OneNand) 별도 controller (CPU 내장) 를 사용한다
. ONIF : Open NAND Interface 국제규약 (신호선 및 Command, 하기 table 참조 )
. Command read 는 page 단위 로 진행하고 program, erase 는 block 단위로 진행한다
. Read 및 Program 시 Multi cycle 이며, 이런 사유로 일반적으로 ROM 용도로는 사용이 불가 하다
(ROM 용도 로 사용하기 위하여 특별한 방법을 적용하며, 이것 적용 된 것이 OneNand 와 eMMC 이다)
. OOM (Out Of Memory) : Page 별 존재하며, Bad Block 여부와 ECC 보정정보 가 들어가 있다
. 수명에 제한이 있다 (SLC – around 80K, MLC – around 5K)
NAND
Controller
SLC MLC
(Blocks)
Block 1
Block 2
Block n
Page 1
Page 2
Page n
OOM
OOM
OOM
.
.
.
.
.
.
64KB or 128KB 512B or 2048B
CPU ONIF
Command CMD Cycle 설명
Read Read data output Cache read Exit cache read Page program Random data input Copy back program Cache program Block erase Reset
2 2 2 1 2 1 4 2 2 1
Page 전체를 read 가능하고, 지정된 address 는 readPtr 개념임 상기 Read operation 중 에 동일한 page 내에서 readPtr 이동임 다음 Page 를 연속 read 할때 Page 전체를 write 가능하고, 지정된 address 는 writePtr 개념임 상기 write operation 중 에 동일한 page 내에서 writePtr 이동임 Bad block 을 관리하는 목적으로 사용 Erase all pages in a block Reset the Device
28
File System
NAND Flash 관리
. Embedded Target 시스템의 Firmware 혹은 사용자 Data file system 이 관리되는 기억장치 임으로 신뢰도 가 중요하며
. 아래 와 같은 5가지 관리방법이 적용 되어야 한다
관리방법 특징
Bad Block Management . NAND 저장장치는 Factory 혹은 사용 중에 사용 불가능 상태로 빠지며 이를 Bad Block 이라고 칭한다 . BBM 관리는 File system 혹은 Raw Block 을 사용하는 Application Layer 의 역할 . 일반적으로 Skip 기법 (50개중, 43번 이 BB 이면, 43번이 요청 와도 51번을 배정하는 방법) 을 적용한다 . Skip 기법은 MTD Layer 에서 통상 구현한다 . Bad Block Flag 관리는 OOM 영역에다 적용 (NAND controller 가 자체적으로 Flag 한다)
Wear Leveling . Write 시 free 영역에 분산하여 Life cycle 을 연장하여는 목적 . 일반적으로 아래 두가 지 방법이 사용된다 (1) Level-1 : 가장 작은 write cycle 을 지닌 data 에 대하여 새로운 free block 을 배정한다. (2) Level-2 : Long-lived data block 을 다른 block 에 이동하고, 해당 block 을 빈번한 write 가 있는 data 의 block 으 로 사용한다. . 일반적으로 파일 system 에서 본 기능이 적용되어 잇다
Garbage Collection . Page (Valid, Invalid, Free ) 간에 Disk 정리 개념 (Block 이 아닌 Page 를 대상으로 한다) . Data page 를 update 시 첫번 째 avaliable page (Free page) 에 write 를 하는 것이 가장 빠름을 이용 하는것 . 통상적으로 미 사용한다
ECC (Error Correction Code)
. 일반적으로 NAND Controller 가 본 기능을 지니고 있다 (Verilog 사 원천기술 ?)
. ECC 보정정보는 OOM 영역에서 관리된다
. ECC Bit 가 작을 수록 신뢰도는 좋으며 SLC 는 주로 4 bit ECC 를 사용하며 MLC 는 주로 24 bit ECC 를 사용한다 1 bit 인 경우 3 Byte, 4 bit 인 경우 7 Byte, 24 Bit 인 경우 44 Byte 보정정보를 사용한다. . 원리는 아래와 같다 (1) program 시 ECC 보정정보 (A) 를 OOM 영역에 기록한다 (2) page read 시 임시 ECC 보정정보 (B) 를 만들어, A 와 B 결과에 따라 아래와 같이 세가지로 나누어진다 보정불필요, 보정필요 – correctable, 보정필요 - uncorrectable (3) Uncorrectable 로 판명된 Page 이면, Bad Block 으로 관리 되어야 한다
Write Protection . 전원 On Off 시 내부 state machine 의 오류를 야기하는 전기적인 Shock 방지목적 . HW Interface (GPIO) 를 사용함으로 DDL Layer 에서 기능 적용
29
Debug
GDB – Core Dump
. 코어덤프(core dump)란 프로세스가 알 수 없는 내부 에러 또는 시그널(signal)을 받아서 코어의 내용을 디스크에 남기는 경우를 말한다. 여기서 `코어' 란 주 저장 장치 즉 RAM을 가리키는 오래 된 용어이다. 이 코어 파일을 나중에 GDB 등의 Debugger를 사용하여 프로그램의 종료 상황과 버그를 찾아내는데 이용하며, 코어덤프를 메모리덤프(memory dump)라고 부르기도 한다. . 일반적인 사용 순서는 아래와 같다 1) GDB 실행 Image 제작 2) Core dump 파일 생성 속성 지정 3) 확보 된 Core dump 파일을 Linux 개발환경 (GDB) 로 이동 4) Call Trace 진행 . GDB 실행 Image 제작 : 아래 두 가지 경우가 적용되어야 한다 1) Compile Option 처리 : -s : ld Option, 실행 화일에서 symbol table 을 제거, 이 Option 은 없어야 한다 -g : cc1 Option, gdb 에게 제공하는 정보를 Binary 에 삽입한다, 이 Option 은 추가되어야 한다 2) Signal Handler 제거 : Main code 에 Signal Handler 가 있다면 core dump 는 출력되지 않는다. . Kernel 구동 후 아래 두 가지 Core dump 파일을 생성하는 속성을 Kernel 에게 지정한다 1) Size : ulimit -c 옵션을 사용한다 (ulimit -c unlimited, 안 만들도록 설정은 ulimit -c 0) 2) 생성 Pattern 에 대하여 'core_pattern' 파일에 속성을 명시한다 : echo mnt/usb/core-%e-%p-%s-%h-%t >/proc/sys/kernel/core_pattern : %e=실행파일이름,%p=죽은 pid,%s=발생한 signal,%h=실행한 host 이름,%t=실행 시간
30
Debug
GDB – Core Dump
. 서버에 아래 세가지 를 탑재하여, back trace 결과를 얻는다 (1) Share Objects (2) GDB 실행 Image (3) 생성된 Core Dump 파일 . 세부과정
1. Shared Objects Linux 서버에서 GDB 환경 구성시 타겟의 Root File System 과 유사하게 SO Lib. 들을 다음 예와 같이 위치시킨다 /home/coredump/usr/lib /home/coredump/lib /home/coredump/myproject 2. GDB 실행 Image 를 Load 시키고, SO path 를 지정한다 > mipsel-uclibc-gdb "실행Image이름" GDB> set solib-absolute-prefix /home/coredump/ GDB> set solib-search-path /myproject 3. Core Dump 파일을 Load 시키고 backtrace 를 실행 시킨다 GDB> core "core_file_name" ; load core dump file GDB> backtrace 주1. gdbInit 실행 script 파일을 "/root/" 밑에 위치시키면 GDB 실행 시 자동호출 됨으로 상기 과정은 이를 이용한다 주2. prefix 만 지정하여도 "/lib" 및 "/usr/lib" 는 default 로 포함한다 주3. 기타 GDB command GDB> print 변수이름 ; 광역변수 값 display GDB> info symbol "address"
31
Debug
GDB - Run Application & Debug
. gdb /usr/bin/myApp
. Commands
break Set break point e.g. break Class::Member condition Set condition on a break point e.g. (gdb) condition 1 bCheck == true enable Enable a break point e.g. enable 1 disable Disable a break point e.g. disable 1 next Execute next line after a breakpoint finish Execute current function and return return Return without executing current function frame Move to a stack frame. e.g frame 1
32
Debug
Kernel hacking
. Lockup 이슈 발생시 유용하게 사용
. Soft Lockup 이나 Hung Task 에 의하여 Kernel Panic (Reboot) 발생 시킨다
. Kernel Image 제작 시 아래 Option 처리
Kernel hacking->Kernel debug Kernel hacking->Kernel debug->Debug shared IRQ handlers Kernel hacking->Kernel debug->Detect Hard and Soft Lockups
Kernel hacking->Detect Hung Tasks
Kernel hacking->Magic SysRq key
Kernel hacking->Panic (Reboot) On Soft Lockups Kernel hacking->Panic (Reboot) On Hung Tasks
strace . 특정 Process 가 사용한 system call 에 대한 List 기능이다 . 특정 Process 가 이상상태 (lockup 혹은 killed) 이며 본 기능을 사용하여 상태파악에 도움이 된다 . strace –p 1000 : Process ID 1000 이 사용한 system call 을 본다
33
New Features
systemd
. System management daemon
. Boot 과정인 Init Process 를 대체, Process 실행 순서를 순차방식에서 병렬방식 으로 개선
. etc/systemd 아래 설정파일 들 존재
. 개별적인 daemon 들을 systemd 로 통합 : inetd, crond, atd, syslog, watchd
. udev 기능수행
DBUS
. The method of IPC (inter process communication)
. D-Bus is a message-bus system, a way for applications to talk to one another. D-Bus supplies both a system daemon (for events such as "new hardware device added" or "printer queue changed") and a per-user-login-session daemon (for general inter-process communication needs among user applications). The message bus builds on a general one-to-one message passing framework, which any two apps can use to communicate directly (without going through the message bus daemon). Most systems implement a privileged system channel, plus a private channel for each logged-in user, so that available information in the D-Bus registry can be restricted. . D-Bus works with Unix sockets between applications and daemons (applications communicate with each other through a fork of the D-Bus daemon), but work has started to create a "peer-to-peer" socket-type in the Linux kernel able to route messages between applications, leaving the daemon as a top-level manager.[3] The new approach improves speed by halving the number of memory-copy operations.
Driver
1) V4L2 (Video for Linux 2) : General Video driver , Interface with Gstreamer
2) DRM (Direct rendering Manager) : General Graphics & Display Drive , Interface with Graphic Components (open GL)
3) ALSA
Security
1) SMACK (Simple Mandatory Access Control Kernel )
34
Utility - RPM
RPM ( Redhat Package Management )
. Redhat Distribution 에서 시작 하였으나, 각 Distribution Linux 에서 표준 적으로 지원이 되는 Utility 이다
. Package 제작 목적
(1) 소스 RPM (SRPM) 으로 만들어진 소스 file 에 대한 공유
(2) Target 실행용 Object 혹은 Link 용 Shared Object
. Package 내용물 : Data Base 로 관리 되며 {spec, binary} 혹은 {spec, source} 혹은 {spec, binary, source} 로 구성된다
. Target 실행용 절차
(1) Build RPM Package Download Install
(2) Target 실행용 Package 는 Executable Object 혹은 Linking Object (Shared Object) 일 것이다.
(3) 실행 은 사용자 의 역할이며, 설치된 경로 나 실행이름 에 대하여 는 질의명령 (rpm ql) 을 통하여 알 수 있다
35
Utility - RPM
RPM Build
(1) 지정 된 Directory 및 Spec 파일을 필요로 한다
(2) 소스 파일에는 makefile 까지 포함되어, Object type (Executable Object, Shared Object) 을 결정한다
(3) Binary RPM Package 와 Source RPM Package 두 가지 가 산출물 이다
생성된 RPM Package 확인 방법
(1) Source RPM 파일을 임의의 directory 에 copy 후에 다음 command 를 통하여 해제한다
> rpm2cpio myPackage.src.rpm | cpio –i –-make-directories
(2) 아래 와 같이 3가지 내용물이 있어야 한다
myPackage.src.rpm
myPackage.tar.gz
myPackage.spec
(3) myPackage.tar.gz 을 풀어서 Package Build 시 사용된 파일 들을 확인한다
Spec File
makefile RPM Package
(xxx.rpm)
Source Code
Package Generator
rpmbuild make
< Directory for RPM Build > /usr/xxx/SPECS ; spec file /usr/xxx/SOURCES ; source code files /usr/xxx/RPMS ; Binary Package output /usr/xxx/BUILD ; Package 에 포함될 파일 및 Directory /usr/xxx/SRPM ; Source Package output (src.rpm)
Build 시 spec file 을 참고하여 compile 한다 SRPM Package (xxx.src.rpm)
36
Utility - RPM
RPM Spec 파일
. Build 부터 설치 과정의 상세 Action 이 담긴 Meta File 이다 (결과물 인 RPM Package 에 meta 파일로 포함 되어진다)
. Header & Macro
분류 Name Description 예
Header Summary Name Version Release License Group Source0 Patch BuildRequires
Package 간략 소개 Package Name 버전 릴리즈 번호 오픈소스 라이선스 대상 들 (GPL, LGPL,,,) 원본소스 code 파일 들 원본소스 code 파일 들 을 대체하는 Patch 의존성 Lib. 명기
Macro %define %description %prep %setup %build %clean %install %pre %preun %post %postun %files
상수, Path define Package 상세설명 빌드 준비작업 -1 빌드 준비작업 -2 빌드 실행 설치 전 실행 할 것 Uninstall 전 실행 할 것 설치 후 실행 할 것 Uninstall 후 실행 할 것 설치되는 파일 목록
-LIB_PATH /usr/lib/ cmake make Make install ldconfig
Devel Macro
%description devel %package devel %files devel
Header 파일 및 package config 파일
37
Utility - RPM
다운로드 및 설치
. Package 를 wget 방법으로 다운로드 받아 Target System 의 File System 에 설치한다
(Root File system 의 SO Lib. Path 와 설치된 위치의 file system 과는 symbolic link 되어져 있을 것 이다)
RPM RPM
Package Exe. Object
Linking Object
서버 Target System
< RPM command > rpm -Uvh package_name // 설치, Upgrade rpm -ivh --replacepkgs package_name // 기존 package를 삭제 후 새로운 package로 변경 rpm -Uvh --oldpackage package_name // 강제로 이전 버전으로 package를 downgrade rpm -e httpd // 설치된 package 삭제 rpm -qa | grep httpd // 설치된 package 중 검색 rpm –qi package_name // 설치된 package 간략 정보 rpm -ql package_name // 설치된 package 파일 내용 < Option > --force : 강제로 설치한다. --replacepkgs, --replacefiles, --oldpackage를 함께 사용하는 격이다. --nodeps: 의존성를 무시하고 진행하라는 옵션으로 설치 후에 문제가 생길 가능성이 많으므로 주의 하는 것이 좋다
wget --no-check-certificate --no-cookies --header "Cookie: oraclelicense=accept-securebackup-cookie" -O jdk-7u55- linux-x64.rpm http://download.oracle.com/otn- pub/java/jdk/7u55-b13/jdk-7u55-linux-x64.rpm Install
38
Utility - RPM
devel Package 사용
. 나의 package 를 참조 하는 (의존성을 지니는) 타 Package Build 시 필요하며, 아래와 같이 세가지 결과물을 포함한다
(1) Binary RPM ; Link 필요성으로 제공한다
(2) Header Files ; directory 이름은 /usr/xxx/include 를 사용한다
(3) package config 파일 ; directory 이름은 /usr/xxx/include 를 사용한다 , cmake 에서 제공하는 commnd 를 이용해 만들 수 있다
. devel package 는 spec 파일에서 지니는 (%files devel) 내용에 의하여 만들어 질 것이다
. 타 Package 가 myPackge 를 참조하는 내용은 아래와 같다
< spec 파일 > Buildrequires: cmake Buildrequires: pkgconfig (myPackage) // 참조 Buildrequires: gettext-devel < cMakefile.txt 파일 > INCLUDE (FindPkgConfig) pkg_check_modules (myPackage) // 참조 < Main.c 파일 > #include “myPackage.h” // 참조