9. 오퍼레이팅 시스템 구조 : 레이어, 마이크로커널, 모듈, 버츄어머신

 

* simple structure 

- 현재는 사용되지 않는 구조

- 모듈이나 레이어로 나뉘어지지 않음

- 듀얼 모드가 되어있지 않음

- 하드웨어 보호가 안됨

e.g. MS-DOS

- 응용 프로그램들은 기본 io연산을 디바이스에 직접할 수 있음

- 유저레벨에서 하드웨어를 직접적으로 건드릴 수 있음

- 응용프로그램이 리소스를 건드리면 시스템이 망가질 가능성이 커짐

 

엄격하게 커널과 유저모드를 구분해서 하드웨어 관리는 커널이 해야함

 

 

* layered 

- 리눅스, 유닉스에서 사용되는 구조

- 각 레이어는 하부레이어에서 제공되는 연산으로만 구현되어야함

e.g. 시스템콜 : 시스템콜 인터페이스는 커널(낮은계층)에서 제공, 유저(상위 계층)는 커널에서 제공하는 인터페이스만 사용

- 프로그램 작성 시 각 레이어에 대해서만 걱정하면 되고, 하부 레이어들은 이미 검증 다됨 

유닉스 시스템 구조

- 사용자는 응용프로그램과 시스템프로그램으로 커널에 접근

- 시스템콜 인터페이스로 디앵힌 함수와 프로그램 접근 가능

- 커널은 하드웨어 관리/ 하드웨어들은 최하위 레벨

 

 

* 마이크로 커널 구조

- 많은 커널 본연의 기능을 유저 스페이스로 옮김

- 장점 : 커널 확장이 쉬움, 새로운 cpu수행 시 유저 수정하면 됨, 유저 수정이 쉬움, 커널 코드 양이 적어서 안정적, 디버깅 용이

            필요한 기능 유저에 추가 + 제거 용이 -> 확장성, 이식성

- 단점 : 프로세스 개수가 많아지고, 유저간 커뮤니케이션이 잦아서 메세지 패싱 오버헤드가 큼

e.g. Mach OS, QnX (임베디드 할때 많이 사용한다함(?))

- 반대되는 개념 : monolithic kernel

 

*모듈

- 계층이 아닌 기능으로 분할

솔라리스 

- 각 모듈 커널 내에서 필요에 따라 로딩, 업로딩이 가능한 구조

  e.g. 디바이스 - 버스 드라이버가 필요 없으면 그냥 혼자 제거되면 됨

- 리눅스는 기본적으로 layered인데 모듈도 추가함 - 디바이스 드라이버

  디바이스 구동 e.g. 새로운 usb를 꽂으면 제어하는 드라이버가 설치되어야 함(입출력장치니까 커널에 있는 디바이스임)

  insmod : 새로운 모듈 추가 시 커널 컴파일 말고 insmod로 동적 추가

  rmmod : 모듈 삭제 시 사용

 

* virtual machine

- 여러개의 서로 다른 os를 하나의 하드웨어에 동시에 수행하기 위해 도입

- 장점 : os 개수만큼 기기를 사지 않아도 됨

- 단점 : 구현이 어려움

- 왼쪽은 각 os가 별도의 physical hardware를 가짐

- 오른쪽은 하드웨어는 하나지만 각 운영체제가 각자의 virtual machine 소유

- 시스템 유지 비용 절약, 소프트웨어 개발 시간 감소

 

- 핵심 소프트웨어 요소는 virtualization layer : 반드시 탑재되고 그 위에 별도의 os 작동

  virtualization layer입장에서는 virtual machin까지만 커널이라고 생각하고 그 위에 os는 모두 유저 프로세서라 생각

  virtual machine 위에서 동작하는 것들이 virtual 유저 스페이스를 갖고 있다고 생각 = virtual kernel

vm ware

- 맨 왼쪽은 호스트 os를 직접쓰는 어플리케이션

- virtualization layer 위에 별도의 os를 작성

- 기본적으로 깔린 시스템(호스트os) 위에 레이어 탑재