[OS] 4. 운영체제 구조(2)

 

* 다음 강의 필기임

https://www.youtube.com/watch?v=VZ1etbiExPo&list=PLl7a4hCkdyMCPNT-3U3fzyb6FEBCS0Ddm&index=4

 

Layer

- 모듈러리티랑 다른 점: 각 레이어들끼리의 연결이 이미 정해져 있음. order이 없음.

- 레이어의 semantics(의미, 함의): 레이어들을 건너뛸 수 없다는 것. 반드시 거쳐야 하게 된다는 것. 그리고 위 아래로만 연결 가능하다는 점. order이 있다는 점.

 

MSDOS

초창기 PC. 레이어링이 매우 불안정했다 -> App을 다루는 사람들이 잘못 접근해서 시스템(커널)을 망가뜨리거나 하는 경우가 자주 발생.

-> 요즘의 커널은 modular하게 잘 되어있음.

 

여러 모듈들이 있고, 커널 단이랑 디바이스 드라이버단을 나눠놓는다. 디바이스 드라이버는 굉장히 하드웨어 디펜던트함. virtual memory와 file system은 굉장히 밀접하게 연결되어 있기 떄문에 레이어를 여러 개 두기가 힘듦. 하지만 모듈러 하게 만듦으로써 읽기 쉽게 하고자 함

 

CPU의 execution 모드

: 최소 2개 모드를 가짐

- Kernel mode

- User mode: 각종 application들이 이렇게 돌아감.

유저 모드일땐 cpu가 그 바이너리(프로그램)을 유저 모드에서 실행을 시킨다 = 유저가 고의든 실수든 디바이스에 직접 접근하려는 것을 막음.

- 실행 과정에서 instruction이 실행될 수 있는 privilege가 달라짐. 유저모드에서는 커널 모드에서 돌아갈 수 있는 instruction들이 돌아가지 않음.

- 예를 들어 인텔에서 io를 처리하기 위해 in/out(어셈블리) 이라는 instruction 이 있다. 이런 명령어는 user 모드에선 동작하지 않음. - 이게 각 모드가 가진 privilege임.

- 인텔 프로세서에서는 wing이라는 메커니즘을 제공. 이 윙이 exe 모드를 제공한다. 커널은 wing zero에서 돌아가고 user는 wing three에서 돌아간다. (중간에 one, two는 지정이 안되어있는데, 나중에 혹시 모르니까 중간에 단계 놔둔 거 → virtualization을 하게 되면 윙을 하나 더 쓰게 됨. 즉, exe 모드가 하나 더 생긴다. virtualization에서 guest는 커널도 유저도 아닌 중간 정도의 권한을 가진다.)

- context 스위칭을 한다는 것.은 결국 이런 모드들 간에 왔다갔다 하는 것이다.

 

* 설계의 중요성

- 인텔 프로세스에서 execution모드를 혹시 모를 미래 상황에 대비해 중간에 2개의 모드를 남긴 것 -> virtualization이 등장하면서 이 빈 모드들을 사용하게 됨

- IP주소 32비트 -> 현재 너무 부족해서 NAT등 다양한 기법을 고안해내야 함. 설계 망한 케이스.

 

Q. 그럼 커널 모드가 sudo랑 비슷한건가? (sudo = superuser)

sudo는 사용자 관점에서의 권한을 다루는 것. 아무리 sudo를 사용한다고 해도 커널 모드를 사용할 수는 없음. protection을 다루는 여러 레벨에서, suo는 사용자 레벨에서의 권한에 내용에 대한 내용이지, 디바이스 접근에 대한 권한 측면의 레벨이 아니다.

유저모드 내에서도 권한의 정도가 나뉜다. 어떤 권한을 줄 것인가를 정의하는 게 운영체제이다. 위에서 말하는 커널 모드와 유저 모드는 하드웨어단에서 권한을 이미 나눠버린 것. sudo는 소프트웨어적인 것.

 

Q. BIOS?

BIOS는 펌웨어 적인 것. 하드웨어를 세팅하고 값을 주는 것이지, 커널 모드/유저 모드를 논할 단계 전인거임. 아직 os가 시동되지 않은 것.

 

커널 모드

커널 모드는 모든 권한을 갖고 있고, 운영체제가 시행이 되는 파트이다. io 장치 명령어, 메모리 매니지먼트 등

ex) cr3 (인텔) 프로세스가 수행되면, 이를 가리키고 있는 것이 cr3. 스위칭을 한다는 것은 cr3의 값을 바꿔준다는 것이다.이런 접근을 커널 모드에서 한다.

https://en.wikipedia.org/wiki/Control_register#CR3

 

* CR3: Control Register 중 하나. 가상 주소화를 사용할 때 사용. PG 비트가 CR0에 설정되어 있을 때 CR3는 현재 task의 page directory와 페이지 테이블을 찾아서 프로세스가 linear adr를 물리적 주소로 바꿔준다. 전형적으로, 상위 20 비트는 page directory base register(첫 페이지 디렉터리 엔트리의 물리적 주소를 갖고 있다)이 된다. 만약 PCIDE 비트가 설정되면 (-> process context identifier들을 enable함), 하위 12비트는 Process context identifier로 사용된다.

 

유저모드

- 커널모드가 아닌 것. 상대적으로 권한이 적고, App 수행한다.

 

유저모드에서 커널모드로 들어갈 일이 분명 생길텐데 그럴 때 어떡하지? -> system call

 

System Call

- 유저모드에서 커널모드로 가는 통로. 유저가 커널로 하여금 서비스를 받을 수 있도록 함. file을 읽을 수 있고, 패킷을 읽을 수 있게 하는 것이 system call.

- 유저모드와 커널모드 간 스위칭을 통해 유저 프로그램이 커널을 호출하고 디바이스에 접근할 수 있다.

 

* 유닉스에서 쓰는 방식

- 1번이라는 것은 명령어, 2번은 system call, 3번은 library 이런 식으로 번호가 지정되어 있음. 똑같은 이름인데, 번호가 달라질 수 있다. (번호를 붙임으로서 명령어, 시스템 콜, 라이브러리 함수인 것을 구분할 수 있는 것)

- 예를 들어, open(2) 이런 식으로 되어 있으면 열기 동작 "시스템 콜"이구나 한다.

- 참고: https://blockdmask.tistory.com/24

 

어떤 문서가 있는 것은 8번이다..?

 

Ex)

open(2)이라는 것을 하면 유저모드에서 커널모드로 스위칭이 일어나서 open() 일을 할 수 있는 커널 함수로 가게 됨. 시스템 콜을 할 때 넘어가는 argument들은 register을 사용하고 부족하면 스택에 넣어서 넘긴다.

 

- 시스템 콜시, argument 세 개까지는 레지스터를 이용하고 넘어가면 스택을 이용하는 것이 일반적이다. (컴파일러와 관련한 부분)

- return 받는 것도 똑같이 받음.

- sys_call.h(커널 소스 코드 파일): 시스템 콜이랑 그 번호가 나와있음.

 

 

커널의 구조

- 앱과 커널 사이에는 시스템 콜 인터페이스가 존재한다.

- 하드웨어 사이에는 드라이버 인터페이스가 있다.

- 커널과 디바이스 드라이버를 구분시킨다. 디바이스 드라이버는 굉장히 highly device dependent하기 때문에.

 

1. monolithic kernel

우리가 현재 사용하고 있는 많은 OS의 커널. 커널과 사용자가 같은 주소 공간을 이용한다.

- monolithic: 한 덩어리

- 32 비트의 주소 → 4 GB의 공간, (4G의 의미)

- 3GB를 app이 쓰고 1GB는 커널이 쓴다. (물론 최근 64비트 운영체제는 좀 다름)

- 장점: 같은 주소 공간에 있기 때문에 커널을 호출하고 커널을 사용하는 비용/시간이 굉장히 적음. 커널의 오버헤드가 적음. 커널에게 가장 중요한 것은 성능.

- 단점; 커널 코드가 엄청 많으면 디버깅하기가 힘듦. maintenance 문제. 버그 하나가 전체에 영향을 미침. architecture 적으로는 그렇게 좋은 구조가 아님.

 

2. micro kernel

- 커널을 쪼갬. 메모리를 관리하는 것. cpu 스케줄링 하는 것, 파일 부분 등 다 모듈화.

- 각각 독립된 주소 공간에서 실행함. 그래서 부분끼리 소통을 해야 함. adr space가 같으면 그냥 함수 호출해서 접근하면 됨. 하지만 adr space가 다르면 메세지 passing이 필요.

- privileged server: 각 파트에서 통신 기능을 한다. message passing을 할 수 있도록 함. 커널에서 IPC라던지 privileged server이 하는 기능을 micro kernel에 넣고 있는 것.

- 이러한 구조 전체를 micro kernel이라고 하기도 하고 통신을 해주는 중추가 micro kernel이라고 부르기도 함.

- 예를 들어서 monolithic kernel에서는 system call을 타고 들어가고 들어가서 최종적으로 disk 에 write가 동작한다. micro kernel에서는 다 message passing으로 해결한다.

 

- monolithic kernel의 경우: App이 microkernel에게 파일 써주세요!하고 메세지를 보내면(함수 호출) 커널이 VFS를 가야하네, 하고 VFS를 호출한다(여기서부터 다 system call). VFS가 ext를 호출, 디바이스 드라이버를 통해 디바이스에 쓰고 다시 타고(리턴 리턴...) 올라옴. → 굉장히 복잡함.

 

 

(출처: https://en.wikipedia.org/wiki/Microkernel )

 

- 장점: 커널 서비스 서버가 따로 있어서 서로 의존성이 낮아서 독립적 개발 가능. 커널 서비스는 서로 끼웠다가 내렸다가 할 수 있다. 즉 vfs를 끼웠다가 내렸다가 하는 식으로 할 수 있음. 그럴 때 ext와 디바이스 드라이버는 영향을 받지 않음. 즉 일부를 동적으로 내렸다 올렸다 할 수 있음.

- 단점: 메세지 패싱이 많이 필요함. → 성능이 안나옴.

 

3. hypervisor (Xen)

클라우드가 보편화되고 있는데, 이걸 하기 위해서는 가상화를 이해해야 하고, 이를 위해서 하이퍼바이저라는 것을 알아야 한다.

ex) 마이크로소프트: 이제 os 만으로는 돈을 못벌겠다 싶으니까 클라우드를 제공하고 거기서 수익 창출을 하겠다라고 함.

 

* 커널은 항상 메모리에 전부 올라가 있다.

* 마이크로 커널 구조에서 가장 중요하고 기본적인 기능을 하는 건 어디에 존재하는가?

monolithic에서는 address space를 공유한다고 했는데, 그럼 microkernel은 어떻게?