OS Project

앞으로 6주간 운영체제(Operating system) 프로젝트가 진행된다. 먼저, 개요(overview)부터 훑어보자. youtube에 있는 "[Course] Operating System (CPA310) - 운영체제 강의"를 토대로 정리했다. 사진 등의 출처도 모두

OS의 많은 역할 중 Process management에 대해 공부해보자.프로세스란 실행중인 프로그램이라고 생각하면 된다. 커널에 등록되고 커널의 관리 하에 있는 작업각종 자원들을 요청하고 할당받을 수 있는 개체프로세스 관리 블록(PCB)을 할당받은 개체 PCB는 각

이제 설연휴 제외 5주간, OS Project에 들어간다.스탠포드에서 교육용으로 만든 OS인 핀토스를 활용하는데, 카이스트에서 일부 내용을 수정한 핀토스를 활용한다.핀토스 프로젝트의 과제는 크게 다음과 같이 4단계(?)로 나뉜다.1번 과제는 독릭접이라고 할 수 있고,

pintOS 과제는 프로세스와 스레드를 동일하게 여기고 진행하면 된다. (굳이 비유하자면 멀티 프로세스, 단일 스레드 개념)기본 제공되는 pintOS는 프로세스를 재우고 깨우는 기능이 Busy-Waiting 방식으로 구현돼있다.이게 무슨 소리냐면, OS에서 A라는 프로

Process Scheduling 단어 그대로 프로세스들을 스케쥴링하는 것이 Process Scheduling이다. 아래 그림에서 어떤 Process(여기 과제에서는 스레드 = 프로세스)가 Ready, Run, Sleep이 일어나야 하는지 정해주는 것이라고 할 수 있다

pintOS 프로젝트 중 앞 포스팅에서 살펴본, 스케쥴링에 대해 시간순으로 하는 것이 아니라 우선순위 별로 진행할 수 있도록 짜는 것이 목표다.앞에서 살펴본 그림에서 처럼, cpu에서 running할 스레드는 ready_list에 순서대로 놓여있었다. 이제 ready_

앞에서 봤듯, 우리는 이제 스레드들이 가지고 있는 우선순위에 따라 cpu를 점유할 수 있도록 만들어줬다.현재의 스레드들은 아래와 같은 특성들을 갖는다.스레드(프로세스)들이 서로에 대해 모르는 상태여러 스레드(프로세스)들이 시스템 상에 존재위의 특성들로 인해, 병행 수행

앞에서 semaphore를 통해 Critical section에 여러 개의 스레드(프로세스)의 접근을 막는 것을 배웠다. 그러나 아래와 같은 문제가 있다.위의 사진의 문제는 파란색, 보라색, 주황색 스레드가 우선순위 순으로 waiters에 대기하지 않고 Lock요청 순

lock 구조체를 살펴보면 아래와 같다. holder(thread 구조체를 가리키는 포인터)와 semaphore 구조체를 갖고 있다.즉, lock 구조체 안에 semaphore가 있는 것인데 그로 인해 얻을 수 있는 내용을 알아보자.앞의 포스팅에서 semaphore로

유저모드(User mode)와 커널모드(Kernel mode) 요약부터 확인해보자.요약 : 커널에서 중요 자원들을 관리하기 때문에, 사용자가 중요한 자원에 접근하지 못하도록 모드를 나눈 것이라고 보면 된다.유저(사용자)가 접근할 수 있는 영역을 제한적으로 두고, 프로그

Argument Passing은 Argument를 나눠주는 띄어쓰기 별로 나눠주는 Argument Parsing과 Parsing된 Argument들을 User stack 넘겨주는 Argument Passing의 두 기능을 포함한다고 할 수 있다. Argument

pintOS에서 구현해야 하는 System call 종류는 아래와 같다.project2에서 구현할 14개의 시스템콜 코드를 알아보기 전에 시스템 콜 핸들러(System call handler)에 대해 알아보자.시스템 콜 핸들러에서 시스템 콜 번호를 이용하여, 해당 시스

앞의 포스팅에서 말했듯, project2에서 구현할 14개의 시스템콜 중에서 7개를 먼저 확인해보자.pintOS를 종료시키는 명령으로, 간단하게 아래와 같이 나타낸다.현재 thread(process)를 종료시키는 명령이다. status가 0인 경우가 정상종료 되는 경우

나머지 7개 시스템 콜에 대해 알아보자.project2에서 구현해야하는 시스템 콜들을 구현해봤다. 아직 시스템콜에 대해서 100% 이해하지 못했다. OS 프로젝트가 끝날 때까지 차근차근 이해를 위해 노력해보자.열린 파일(fd)의 크기를 리턴한다. (바이트 크기)파일(f

커널(Kernel)은 전원을 켰을 때, 메모리로 올라와 시스템이 동작되는 동안 계속 머무르는 부분이다. OS에서 가장 기초적이고 핵심적인 기능을 담당한다.위의 그림에서 Hard Ware를 Kernel이 감싸고 있는 이유는, 커널이 하드웨어를 제어하기 때문이다.또, Us

원래 pintOS에서 fork는 구현하지 않는데, kaist pintOS에서는 fork() 함수를 구현한다.공식 깃북에는 아래와 같이 설명이 돼있다.요약하자면, 현재 프로세스의 복제 프로세스를 만든다.1\. 현재 스레드의 interrupt_frame을 복제한다.2\.

가상메모리는 메모리로서 실존하지 않지만, 사용자에게 메모리 역할을 하는 "메모리"라고 생각하면 된다. 프로그램이 수용될 때, 가상메모리의 크기에 맞추 수용된다. 그러나 가상메모리에 수용된 프로그램이 실행될 때는, 물리메모리(RAM)가 필요하다.물리메모리보다 큰 프로그램

projectlazy load segment를 알아보기 전에 load segment를 알아보자.pintos에서는 load_segment() 함수를 활용해 kernel주소(kpage)에 file을 모두 load 시킨다. 그리고 유저스택 page(upage)와 kernel

Setup-Stack은 말 그대로, 초기에 스택영역을 초기화해주는 과정이다.기존에 구현돼있는 Setup-Stack은 아래와 같은데,즉, kapge에 1페이지를 할당 받아서 page table mapping시켜주는 것이다.(실패하면, 다시 palloc_free를 해주고)

우리가 앞선 프로젝트1~2에서 계속 다뤘던, thread구조체에 존재한다. spt라는 이름을 가진 supplemental_page_table라는 구조체다. vm.h에 아래 주석과 같이 이미 설명이 돼있는데, 우리 조는 hash구조체만 들어가있는 table이다.lazy

아래와 같이 vm.h 에 구현이 돼있다.project4에서 쓰일 VM_PAGE_CACHE말고 위의 3개를 알아보자.한 번도 메모리에 load(initialize)되지 않은 것으로, uninit상태에서는 vm_anon혹은 vm_file타입으로 변할 가능성(?)을 갖고있다

mmap()과 munmap()은 모두 시스템콜으로, mmap()은 디스크에 있는 파일 정보를 미리(사용자 몰래?) memory에 load시켜 두어 접근 속도를 빠르게 만들어주는 교묘한 기술이라고 할 수 있다. munmap()은 mmap()과 반대로 메모리에서 삭제해주는

우리는 Swap-in / Swap-out 덕분에 메모리가 한계가 없는 것처럼 느낀다. 메모리가 가득 찼을 때, 메모리 공간에서 우리가 원하는(os에서 정하는) page를 disk에 내보낸다. (앞 포스팅에서 말한, file type이라면 disk, anon type이라

파일시스템이란 파일에 대한 전반적인 관리를 할 수 있는 체계라고 보면 된다. 즉, 디스크(disk)와 파일간의 연결, 디렉토리(folder)와 파일간의 연결 등을 관리해주는 방법이라고 생각하면 된다. 특히, pintos에서는 file의 metadata라 할 수 있는 i

디스크에 파일을 할당(저장)하는 방법에 대해 알아보자.3가지 방법을 알아볼 것이고, 우리는 이 중 한 방법을 응용한 FAT 시스템을 활용하여 pintos과제를 진행할 것이다.아래 디스크 그림에서 작은 네모 한 칸이 섹터(pintos 과제에서는 512byte)로 생각하면

앞에서 말했듯 연결 할당 방법의 변형으로 FAT를 활용하여 이번 과제를 진행한다. Disk의 가장 앞 부분에는 Boot Sector를 위치시킨다.그 뒤에 바로 FAT TABLE을 넣어준다.그 뒤에 바로 Root Dir가 위치하고, 그 뒤부터는 진짜 Data들이 저장되는

Directory와 관련된 내용이다. 흔히 폴더라고 부르는 걸 생각하면 되는데, 아래처럼 dir과 관련한 여러 시스템콜 함수들도 구현해야 한다.디렉토리 구조는 아래 그림을 생각하는 것이 좋다. (디렉토리도 일종의 파일이다...)Directory inode와 Direct

깃북의 설명은 매우 간단하다. 흔히 생각하는 바로가기를 만드는 것이다. 그런데 테스트케이스에서 아래와 같이 파일을 나중에 생성해버리는 경우가 있어서 다시 생각해야 했다. 나에게 정말 쉽지 않았다. 운영체제(OS)에 대한 개념도 아예 없는 상태에서 구현 프로젝트를 진행한