운영체제(12) Kernel Mode Programming & Device drive

 

 

 

1. Kernel mode and User mode

 
<Kernel mode 명령어>
(1) LMSW, SMSW : 현재 프로세서의 머신 상태 워드(machine status word)를 로드/ 저장.
(2) MOV DBn, MOV CRn : 디버그 레지스터/ 컨트롤 레지스터를 이동.
(3) LSL : 세그먼트 제한값(segment LImit)을 로드. 
(4) HLT : Halt, 프로세서를 중지. 실행 시 프로세서는 멈추고 대기 상태가 된다. 
-> 메모리의 모든 위치에 액세스, 수정할 수 있다. 
-> CPU 및 장치의 모든 레지스터에 액세스하고 수정할 수 있다. 
-> OS 커널 명령은 커널 모드에서 실행된다. 
 
<When CPU runs in User mode>
-> CPU는 제한된 명령 집합을 사용한다. 
-> CPU는 (프로그램을 실행하는) 프로세스에 할당된 메모리 구역만 수정할 수 있다. 
-> CPU는 CPU의 레지스터 하위 집합에만 액세스할 수 있다. (device의 레지스터에는 접근 불가)
    컴퓨터 자원에 대한 액세스 권한이 제한되어 있다. 
 
<Kernel and User mode>
(1) OS가 부팅되면, Kernel mode에서 시작된다. 
(2) Kernel mode에서, OS는 모든 인터럽트 벡터(interrupt vectors)를 설정하고 모든 장치를 초기화한다.
(3) 그런 다음 첫번째 프로세스를 시작하고, User mode로 전환한다. 
(4) User mode에서는 모든 백그라운스 시스템 프로세스(daemons, services)를 실행한다. 
(5) 그런 다음, user shell 또는 windows manager를 실행한다. 
(6) 사용자 프로그램은 User mode에서 실행된다.
    -> 인터럽트가 발생하면 Kernel mode로 전환된다. 인터럽트가 반환되면 다시 User mode로.
    -> 인터럽트 처리 코드(OS의 일부)는 Kernel mode에서 실행된다. 
        즉, 인터럽트 벡터는 Kernel mode에서만 수정할 수 있다. 
(7) 대부분의 CPU time은 User mode에서 사용된다. 

 
 

2. Separation of user/kernel mode

 
왜 사용자 모드, 커널 모드를 분리하는 것일까?
(1) 보안 : 커널 모드의 OS calls는 사용자가 해당 호출을 실행할 충분한 권한을 가졌는지 확인한다. 
(2) 견고함 : 잘못된 메모리 위치에 쓰려고 시도하는 프로세스가 있으면 OS는 프로그램 종료시킴. 
    그러나 OS는 계속 실행된다. 프로세스 간 충돌이 발생해도 OS는 계속 실행된다. 
(3) 사용자 모드의 버그로 인해 프로그램이 중단되면 -> OS는 계속 실행된다.
    커널 모드의 버그로 인해 -> OS 및 시스템이 중단될 수 있다. 
(4) 공정성 : OS는 사용자 프로세스 간의 공정한 액세스를 보장한다. 
 
<Interrupt must be handled in kernel mode, why?>
인터럽트는 컴퓨터 시스템에서 발생하는 이벤트로, 주로 하드웨어 장치나 예외 상황에 의해 발생한다. 
CPU의 정상적인 실행을 중단하고, 해당 이벤트에 대한 처리를 수행하기 위해 OS로 권한 넘김.
커널 모드는 OS가 하드웨어를 제어하고, 시스템을 관리하는데 필요한 권한과 자원을 갖고 있다. 

 
<Linux Kernel Modules>
커널 모듈 : 런타임에 동적으로 커널에 로드/언로드할 수 있는 코드
-> 시스템을 재부팅할 필요 없이 커널 코드 변경
-> 좀 더 technically : 모듈의 객체 코드는 실행 중인 커널 코드와 동적으로 연결된다. 
-> 리눅스 커널 프로그래밍에서 간단히 ~~ 사용 가능 !!

 
 

3. Rules to write kernel-mode programs

 

Building Module in Kernel Space

 
(1) floating-point(부동 소수점) 연산을 사용하지 마라 !!!
    -> 커널은 모드 전환 시 프로세서의 FP state를 저장하지 않는다. 
(2) 드라이버를 기다리느라 바빠하지 마라 !! 
    -> 커널 내부에서 1초동안 루프가 회전하면, 해당 시간 동안 시스템이 중단되고 실제 작업이 수행되지 X. 
(3) 영리해지려 하지 마라 !!
    -> 커널 공간에서는 디버깅이 훨씬 어렵다. 
    -> 드라이버는 종종 하드웨어를 다룰 때 정확한 타이밍이 필요하다. 
    -> 가능한 깨끗하고, 이해하기 쉬운 코드로 !!
 
 

4. Life Cycle of An I/O Request

 

 
(1) I/O 요청의 시작은 사용자 프로그램에서 발생한다. 
    -> 사용자 프로그램은 I/O 작업을 수행하기 위해 해당 디바이스에 대한 요청을 생성하고, OS로 전달한다. 
    -> 이 요청은 주로 system call을 통해 이루어진다. 
(2) Kernel I/O subsystems :  I/O 요청을 수신하고, 처리하는 역할을 한다. 
    -> OS는 사용자 프로그램의 I/O 요청을 검증하고, 요청을 디바이스 드라이버로 전달한다. 
(3) Device driver : 디바이스 드라이버는 OS와 디바이스 간의 인터페이스 역할을 한다. 
    -> top half(상위 부분)은 요청을 받아들이고, 요청을 처리하기 위한 초기 설정 및 준비를 한다. 
    -> bottom half(하위 부분)은 실제 I/O 작업을 수행하는 역할을 한다. 
        디바이스와의 통신을 관리하고, 데이터 전송이나 상태 변경 등을 주생. 인터럽트를 처리. DMA 제어.
(4) Device hardware : 실제 디바이스 하드웨어가 I/O 작업을 수행한다. 
    -> 하드웨어는 디바이스 드라이버로부터 받은 명령을 실행하고, 데이터 전송을 수행하여 I/O 작업을 완료.
    -> 실제로 데이터를 읽거나 쓰는 등의 작업이 이루어진다.