The content of Linux for seminar

1. Februray 2015
HR Kwon (hungrok@hanmail.net )
IT 강의자료
Linux 기본개념 (Basic Concepts)

2. 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()

3. 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 시

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

5. 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 합니다

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

7. 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. 의존성 파악

8. 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.atest.o
gcc –c test.c ar Cr libtest.a test.o
test.c libtest.sotest.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

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

10. 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 을 지니지 않는다

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

12. 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 들은
표준 입출력 장치를 공용 사용하며
동일한 메모리 공간을 사용한다

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

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

15. 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 반드시 사용

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

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

18. 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 용도

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

20. 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)

21. 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 mtd1HW장치
Device
Driver (mtd)
< 장치화일 명 >
/dev/mtd1
< 사용순서>
open (“/dev/mtd1/aaa”)

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

23. 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)

24. 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_irqINTR
call_ISR
wakeup action
Buffer
< ISR 일반적인 특징 >
1) 가능한 짧은 Syntax 를 지녀야 한다
2) Thread 주 업무 처리를 위하여 wakeup 시킨다
3) 진입시 INTR 은 disable 처리하고
종료시 INTR enable 처리 (clear INT)
4) Kernel privilege API 중 사용금지 사항 존재

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

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

27. 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 정보확인 및 속성변경

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

29. 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 에서 기능 적용

30. 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=실행 시간

31. 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"

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

33. 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 을 본다

34. 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 )

35. 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) 을 통하여 알 수 있다

36. 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)

37. 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 파일

38. 37
Utility - RPM
 다운로드 및 설치
. Package 를 wget 방법으로 다운로드 받아 Target System 의 File System 에 설치한다
(Root File system 의 SO Lib. Path 와 설치된 위치의 file system 과는 symbolic link 되어져 있을 것 이다)
RPMRPM
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

39. 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” // 참조