os system structure

operating system structure는 다음과 같다.

사용자가 보는 user mode와 os의 영역인 kernel mode로 구분하고 이 둘을 연결하는 것이 system call interface이다. 

function call은 사용자가 만든 함수를 호출하는 것이지만 system call은 os가 만든 함수 즉 kernel mode로 진입하게 한다. 윈도우에서는 api라고 부르지만 리눅스는 sys call이다.

 

그럼 언제 운영체제가 system의 controll을 가져가는가?

1. bootstraping: 전원이 켜질때

전원이 켜질 때는 명령어들을 메모리에 올리고 실행해야 한다. 이때 최초의 명령어 주소가 0xffffff0이다.

전원이 꺼져도 남아있어야 하므로 rom bios에 저장된다.

정상적인 경우에는 부트로더를 실행하여 운영체제를 메모리에 올린다.

운영체제는 메모리의 master boot record에 저장되어 있는 것을 올린다.

 

2. system call: sys call이 호출된 상황

 

3. interrupt: interrupt가 발생한 상황

interrupt가 발생하면 cpu가 interrupt handler로 가서 interrupt를 처리한 후 다시 돌아온다.

cpu가 sys call을 통해 자기자신에게 interrupt를 거는 것을 exception이라고 부른다. 

이때 운영체제에게 도움을 요청하고 exception을 발생시킨다.

가장 대표적인게 sigsegv 참조할 수 없는 메모리 영역 참조 등이 있다 1학년 때 포인터 하면서 맨날 만나는 msg라서 반가울 지경

exception에는 두가지가 있다.

1. trap: trap은 의도적인 interrupt다. 예를 들면 디버그 상황 정도?

2. fault: 예상치 못하게 현재 수행하던 일을 마치지 못할 때 발생한다.

 

 

운영체제의 구성요소들을 하나씩 살펴보자

 

process management

- process의 생성과 삭제, 중지와 실행을 담당한다.

program은 하드디스크에 저장된 실행파일이고 이를 실행할 수 있도록 메모리에 올려 인스턴스를 만들면 process가 된다.

 

main memory management -> volatile 즉 system failure인 경우 내용을 잃는다.

- memory의 어떤 영역이 어떤 프로세스에 의해 쓰이고 있는지

- 어떤 process를 memory에 올릴지

- memory space의 allocation과 deallocation

 

file management

파일 관리를 효율적으로 하기 위한 system

abstraction/file/directory

 

i/o system management

i/o system은 3가지로 구성되어 있다

1. buffer cache: 2차 메모리의 효율을 위해 메인 메모리의 일정 부분을 캐시로 사용한다.

2. general device driver interface

3. drivers for specific hardware device

이 system들을 i/o abstraction을 통해서 관리한다.

os는 i/o를 추상화하여 standard interface를 제공한다.

 

second-storage management

main memory는 휘발성이므로 이를 영구 저장하기 위함이다.

- free space management

- storage allocation

- disk scheduling

 

networking

 

protection system

control을 access

- 권한이 있는 자와 없는 자를 구별한다.

- provide means of enforcement

 

command-interpreter system

사용자가 명령어를 입력하면 그걸 운영체제가 해석해서 실행한다.

운영체제가 제공하는 기능을 command 단위로 입력해서 사용한다.

대표적인게 shell

 

system call의 종류

- process control

- information maintenance

- file management

- device management

- communications 

리눅스 시스템 프로그래밍하면 맨날 c로 짜는

mkdir, remove, 같은 file management

fork waitpid thread_create 같은 process control

semaphore나 shmget shmat 같은 ipc를 위한 communication 등등 많다.

 

system call을 발생시키자

count=read(fd, buffer, n)

리눅스 프로그래밍에서 파일을 읽어오는 대표적인 프로그램을 만드는 read system call이다.

call을 요청하면 register에 'read'를 저장한다. 이때 sys call이므로 handler에게 trap을 건다. kernel mode로 진입하여 syscall handler가 이를 처리하고 caller에게 돌아온다.

 

 

os structure

크게 두가지이다. monolithic kernel vs micro kernel

 

monolithic kernel

쉽게 말하면 os에 모든 기능을 때려넣는 것이다.

근데 기능이 os에 자꾸 추가되니 무거워지고 따라서 임베디드에는 적용이 힘들다.

또한 기능들이 서로 얽혀있기 때문에 구현이 복잡하다. 여기서 유지 보수를 해서 기능을 추가해야한다? 아예 구조부터 다 뜯어봐야함...

또한 시스템 기능을 추가하는 경우 모두 재빌드해야한다.

근데 다 os에 있으므로 구성요소들 간의 통신이 효율적이고 데이터 처리 속도가 빠르다.

Ms dos, unix가 여기에 속한다.

 

micro kernel

중요한 기능은 kernel에 둬서 os가 접근하도록 하고 가벼운 것들은 user mode에서 각각 서버 형태로 구현한다.

예를 들면 memory management와 scheduling은 kernel mode에 두고 file system이나 device driver는 user mode에 둘 수 있다. 서로 통신은 message를 주고 받으면서 하면 됨

 

근데 이 둘을 섞은게

hybrid kernel system

user mode에서 사용가능한 것은 시스템을 사용하면서 수정하거나 추가할 기능들만 올리고 나머지는 다 kernel에서 처리한다.

통신의 오버헤드를 줄일 수 있고 중요한 것들은 kernel에 있으니 micro kernel보다 빠르다.