누군가 피워놓은 모닥불

Application과 Kernel 사이를 Module을 활용하여 연결, 파일 연산자 활용.

USB Device Driver - Host Controller(OHCI, EHCI)

GPL - 사용은 무료인데, 만든 소스 코드 공개가 원칙

LGPL(Lease GPL) - GPL보다 상대적으로 라이센스 범위가 좁음

BSD - Source 공개 해도 되고, 안 해도 됨

Kernel version(Major.Minor.Build.Revision)

v1.x -> single CPU

v2.x -> multi CPU

v2.6이하에서는 Odd Version(Development), Even Version(Stable)

Build Version 높을수록 안정적

v3.x - 가상화, 분산형에 관한 업데이트. 임베디드와 관련없는 부분이 많음.

v4.x는 큰 변화 없음.

Linux Kernel Function

1. Process Management (kernel dir)

2. Memory Management(mm dir)

3. File System Management(fs dir) - Linux에서 20~30가지의 파일 시스템 제공

4. Device Control

5. Network Management(net dir)

커널 소스 트리

트리 설계 - Hardware와 dependency, independecy를 따짐

v2.6의 변화

1. Embedded

2. Preemption Kernel

non-preemption (v2.6 미만에서의 version)

• 프로그래밍이 쉽다.

• 안정적

• 주로 서버용

• interactive performance ↓

    3. Scheduler : O(1) algorithm 사용. → interactive performance가 떨어짐.  

- v2.6.2x(진저브레드)에서 CFS(Complete Fair Schedueling)로 변경

    4. Memory 

- MMU 없는 시스템 지원 → uClinux

- r-map(reverse mapping)의 도입으로  MMU 기능 속도 개선

   5. Interrupt Handler 

- 인터럽트 금지 및 해제 함수 변화
-  cli() → local_iqr_disable()
-  sti() → local_iqr_enable()

   6. 기타

- 디바이스 번호 변경(확장)

- 모듈의 변화

초기에는 .o file로 모듈을 만들었으나 .ko file로 변경(커널 버전 정보를 가짐)

Major number = 종류

Minor number = 번호

디바이스 속성 2가지 = 종류(문자 or 블록 or 네트워크), 번호

커널모듈 vs 응용프로그램

응용프로그램 - 유저 영역에 들어있음

커널 모듈 - 커널 영역에 들어있음

가상주소는 항상 위치가 지정

TLB 유저영역은 P1->P2->P3 switching 하면서 수행됨

1. u-boot가 자기 자신을 복사해서 DRAM 가장 상단에 위치

2. tftp를 통해서 zImage를 받아오면 DRAM 중간에 위치시킴

3. 압축을 해제하면 RAM영역 맨 앞으로 위치됨.

4. 커널이 생성되면 page table부터 생성

mknod // 응용프로그램에서 디바이스 파일을 만듦

ex) mknod /dev/test c 240 1

디바이스 드라이버

하드웨어를 사용 가능하게 만들어 줄 뿐 , 하드웨어를 어떻게 사용할지에 대한 결정은 응용 프로그램에 넘김.

Write

유저 쪽에 있는 메모리 복사 -> Copy from user // user가 계속 바뀌므로

copy_from_user(data,buf,count) 데이터를 버퍼에 씀

Read

커널에 있는 데이터를 유저가 읽음 -> copy to user

copy_to_user(buf,data,count) 버퍼에서 데이터를 읽어옴

printf는 중간에 버퍼(tty) 거침 tty -> serial

printk는 console로 바로 출력 serial

디바이스 파일에 저장되는 정보 : 디바이스 타입 정보(Char/Block/Network, 주 번호(Major), 부 번호(Minor))

주 번호 – 응용 프로그램과 디바이스 드라이버를 연결하는 고리

1. 응용 프로그램은 open() 함수로 디바이스 파일을 열면 커널은 해당 디바이스 파일에서 주 번호 얻음.

2. 이 주 번호에 의해 처리하는 디바이스 드라이버를 찾는다.

3. 주 번호로 응용 프로그램과 디바이스 드라이버가 연결되면 부 번호가 처리하고자 하는 실질적인 디바이스를 나타냄

디바이스 파일

일반 파일과 달리 커널 내의 파일 시스템 구조에 의해 하드웨어를 제어하는 디바이스 드라이버 함수와 연결된다. 그래서 응용 프로그램은 하드웨어를 제어하기 위해 저수준 파일 입출력 함수를 사용해 디바이스 파일에 데이터를 쓰거나 읽고, 그 결과로 하드웨어를 제어하는 디바이스 드라이버 함수가 호출된다.

디바이스 드라이버

하드웨어를 제어하기 위해서는 해당 디바이스를 제어하는 함수 집합인 디바이스 드라이버가 커널 내부에 있어야 한다. 이 디바이스 드라이버는 모듈 형태로 커널에 적재될 수도 있고, 처음부터 커널 내부에 구현되어 있을 수도 있다. 그래서 문자 디바이스 드라이버의 경우에는 응용 프로그램에서 해당디바이스 드라이버와 연결된 디바이스 파일을 통해 호출해야하지만, 블록 디바이스 드라이버나 네트워크 디바이스 드라이버는 커널에서 직접 호출해서 사용한다.

문자 디바이스 드라이버 동작

응용 프로그램에서 open() 함수로 디바이스 파일을 열어 타입정보와 주 번호를 얻는다.

이 정보를 이용하여 chrdevs 배열에 등록된 디바이스 드라이버의 인덱스를 얻는다.

여기서 얻은 인덱스 값으로 chrdevs 변수에 등록된 file_operations 구조체 주소를 얻는다.

그리고 이 구조체에는 문자 디바이스 드라이버가 문자 디바이스 드라이버를 등록하는 함수를 사용하여 저 수준 파일 입출력에 대응하는 함수를 설정한 내용을 담고 있다.

결국 디바이스 파일 타입 정보와 주 번호를 이용해 커널 내의 디바이스 드라이버를 찾는다.

file_operations 구조체로 응용 프로그램의 저수준 파일 입출력 함수와 디바이스 드라이버의 함수가 1:1로 맵핑.

응용 프로그램이 디바이스 파일에 저수준 파일 입출력 함수를 적용하면 그에 대응하는 함수가 호출된다.

mknod : 디바이스 파일을 만듦. 가급적 /dev 디렉토리에 만드는 게 좋음

형식 → mknod [디바이스 파일명] [디바이스 파일형] [주 번호] [부 번호]

ex) mknod /dev/devfile c 240 1

CDD(Character Driver Device)

1. 임의의 길이를 갖는 문자열을 다루는 디바이스 드라이버.

2. open(), close(), read(), write()와 같은 파일 처리용 함수 이용하여 일반 파일처럼 다뤄서 H/W 처리 가능

3. 응용프로그램에서 직접 호출된다. 응용프로그램의 호출과 1:1로 대응

4. 버퍼X

BDD(Block Driver Device)

1. 일정 크기의 버퍼를 통해 데이터를 처리하는 디바이스 드라이버.

2. 특별한 경우(파티션 분할)가 아니면 응용프로그램에서 직접적으로 사용하지 않는 디바이스 드라이버

3. 파일 시스템을 지원하는 구조이므로 응용 프로그램은 파일 시스템을 통해 접근한다.

4. 커널 내부의 파일 시스템에서 관리. 내부적인 버퍼가 있는 디바이스 드라이버.

5. CDD의 특성도 가짐. 파일 처리 함수 이용 가능

NDD(Network Driver Device)

1. 네트워크 층과 연결된 디바이스 드라이버

2. 커널 내부에 있는 네트워크 프로토콜 스택과 연동하도록 설계되어 있다. → 그래서 디바이스 파일이 없다

3. 응용 프로그램에서 직접적으로 접근할 수 없다. (예외적으로 ifconfig와 같은 프로그램만 syscall 가능)

4. H/W적인 디바이스 뿐만 아니라 S/W적인 디바이스 드라이버와 연동 가능

make tags // ctags

make cscope // cscope

make -j // 멀티코어 개수의 2배정도 주면 됨. ex) make -j4

make v=1 or make v=0   // make 전체 메시지 출력 verbs 약자