[정글 60일차] Project2 발제

Project1이 끝나고 Project2에 돌입했다. 사실 아직도 Project1이 어떻게 이루어졌는지 이해가 가지 않는다.

Project2는 Project1과는 다르게 다 소화하지 못해도 이해를 바탕으로 차근차근 따라갈 수 있게 노력해야겠다.

 

Project2는 extra 구현 과제를 제외하고 크게 5가지로 나누어 진다. 10일 이내에 이 모든 것을 구현해 내야하기 때문에 상대적으로 시간이 촉박하다고 생각된다.

 

프로젝트 구현 시작 전 과제 설명에 대한 깃북을 읽고, 추가적으로 관련 영상을 참고해서 구현해야겠다. 프로젝트1 당시 깃북만 참고하여 구현해 봤더니 아직까지는 해당 내용만 읽고 수행하기에는 나의 역량이 부족하다는 점을 알게 되었다.

 

따라서 다양한 문서를 참고해서 이해를 바탕으로 이번 프로젝트를 성공적으로 완성하는 것이 나의 목표이다.

---

1. PROJECT2 과제 설명

- Introduction 소개

유저 프로그램을 로드하고 실행하는데 필요한 기본 코드들은 이미 있지만, 현재 코드는 I/O나 상호작용이 가능하지 않다.

이번 과제에서는 시스템 콜을 통해 OS와 상호작용을 할 수 있는 코드를 구현하는 것이 목표다.

userprog 디렉터리 및 디렉터리 밖에서도 작업을 하게 될것이다.

Project1에서 제출한 코드에 이어서 진행할 것이며, 주석에 TO-DO로 명시되어 있지 않다고 변경하면 안된다는 말은 아니다. 테스트 코드를 제외한 나머지는 자유롭게 변경해도 된다.

 

- 배경 지식

기존의 Project1의 코드는 OS 커널의 한 부분으로 시스템에 중요한 부분에 접근할 수 있는 특권을 가지고 실행되었다.

하지만 유저 프로그램은 시스템에 중요한 부분에 접근할 수 있는 특권이 없기 때문에 Project2에서는 이런 상황을 다뤄야 한다.

한 번에 하나 이상의 프로그램이 실행 될 수 있으며 각 프로세스는 하나의 쓰레드를 가진다. 따라서, 유저 프로그램은 자신들의 컴퓨터 전체를 소유한다는 개념으로 이해해도 된다.

하지만 ifdef VM으로 감싸진 곳에 코드를 작성한다면 Project3에서 구현할 부분에 포함되어 있기 때문에 해당 코드 블록 내에 위치해서는 안된다.

시작 전 동기화 부분과 가상메모리 부분을 먼저 읽어야 한다.

 

- 소스 파일 정보

userprog 디렉터리 내 9개의 파일(해당 디렉터리 외에도 존재)을 고치게 될텐데 c파일들은 userprog에 있으며, h 파일은 include/userprog에 위치한다.

• process.c , process.h (수정 필요 O)

ELF 바이너리(= ELF 실행파일)들을 로드하고 프로세스를 실행한다.
*) ELF : ELF는 많은 운영체제에서 목적 파일, 공유 라이브러리, 그리고 실행 파일들을 위해 사용되는 파일 포맷

• syscall-entry.S (수정 필요 X)

시스템 콜 핸들러를 부트스트랩하는 어셈블리 코드로 이해할 필요는 없다.
*) 부트스트랩 프로그램 : 전원을 켜거나 재부팅을 할 때 적재되는 프로그램

• exception.c, exception.h  (수정 필요 O)

유저 프로그램이 특별한 권한을 필요로 하거나 금지된 연산 수행시 exception 또는 fault로 커널 내 트랩한다.
exception.c, exception.h 파일들은 예외사항을 처리하는데 현재는 메세지를 출력하고 프로세스를 끝내고 있어 프로젝트2에서는 page_fault()를 수정해야 한다.

*) 응용 프로그램이 시스템 콜을 호출하면 하드웨어는 '트랩 핸들러'를 실행하여 하드웨어 특권 수준을 커널모드로 격상시킴
*) 커널모드에서 OS는 시스템 하드웨어를 자유롭게 접근 가능

사용자 모드에서는 하드웨어에 직접 접근하여 사용할 수 없기 때문에 트랩 핸들러를 사용하여 커널모드로 변경 후 사용해야 한다.

• gdt.c, gdt.h (수정 필요 X)

x86-64는 segmented 아키텍쳐로 `GDT`는 사용중인 세그먼트들을 알려준다.
해당 파일들은 GDT를 셋업하는데 해당 파일을 수정할 필요는 없지만, GDT가 어떻게 작동하는지 궁금하다면 읽어 보는 것을 추천한다.

• tss.c, tss.h (수정 필요 X)

TSS는 x86 아키텍쳐 Contex Switching에 사용되었지만 x86-64에서는 지원이 중단되었다. 하지만 ring switching 동안 스택 포인터를 찾아내기 위해 사용되고 있다.

스택 포인터를 찾아낸다는건 유저 프로세스가 인터럽트 핸들러에 진입할 때, tss에게 커널의 스택 포인터를 찾아달라고 요청한다는 의미다. 
따라서, 이 파일들을 수정할 필요는 없지만 어떻게 동작하는지 궁금하다면 확인해도 좋다.

 

- 파일 시스템 사용 방법

구현해야하는 시스템 콜들이 파일 시스템을 다루며, 파일 시스템으로부터 로드되기 때문에 해당 코드들을 확인해야한다.

filesys 디렉터리 내 filesys.h와 file.h를 확인하여 파일 시스템을 사용하는 방법과 수많은 제약 사항을 이해할 수 있다.

(하지만 이번 프로젝트에서는 이 파일 시스템 코드를 수정할 필요 없고, 수정하지 않는 것을 권한다. )

 

파일 시스템을 적절히 사용하는 것은 프로젝트4에서 유용하게 활용될 것이기 때문에 아래의 제한 사항들을 지켜줘야 한다.

 

[제한 사항]

(1) 내부 동기화 금지
동기화는 한번에 하나의 프로세스만 파일 시스템 코드를 실행한다는 것을 보장하기 위해서만 사용해라

(2) 파일 사이즈
파일 사이즈는 파일이 생성될 때 고정된다. 따라서 루트 디렉터리 파일이기 때문에 생성될 수 있는 파일의 갯수들도 제한된다.

(3) 디스크 섹터
파일의 데이터는 디스크 섹터를 연속적으로 차지해야 하기 때문에 파일 시스템이 사용되고 시간이 프르면서 외부 단편화가 큰 문제가 될 수 있다.

(4) 하위 디렉터리
하위 디렉터리를 만들면 안된다.

(5) 파일 이름
파일 이름은 14자로 제한된다.

(6) 파일 시스템 복구
디스크를 읽고 쓰는 중에 시스템 crash가 발생하면 디스크를 망칠 수 있으며 파일 시스템 복구틀은 존재하지 않는다.

 

- 중요한 사항들 

filesys_remove()를 위한 유닉스 계열(유닉스는 아닌데, 유닉스와 비슷한)의 semantic들은 구현되어 있다. 
즉, 삭제된 파일이여도 파일을 열었던 스레드를 닫아주지 않는다면 (메모리에서) 블록이 할당 해제되지 않아 다른 스레드들이 해당 파일에 접근할 수 있다.

 

모든 테스트 프로그램들이 커널 이미지로 존재했던 프로젝트1과 달리, 테스트 프로그램을 핀토스 가상 공간에 넣어줘야 한다. make check와 같은 스크립트들이 해당 과정을 자동적으로 수행해 주며 이 과정을 이해한다면 각 테스트 케이스를 돌려볼 때 도움이 될 것이다.

 

pintos 가상 머신에 파일을 넣기 위해서 먼저 파일 시스템 파티션이 있는 모의 디스크를 만들 수 있어야 한다. 

pintos-mkdisk 프로그램이 이 기능을 제공하며 userprog/build 디렉토리에서 pintos-mdisk filesys.dsk 2를 실행한다.

이 명령어는 2MB 크기의 pintos 파일 시스템 파티션 하나를 포함하는 filesys.dsk라는 모의 디스크를 만들며 --fs-disk filesys.dsk를 적어줘 어떤 디스크인지 지정한다. —fs-disk는 모의 커널(simulated kernel)이 아니라 pintos script를 위한 옵션이므로 --를 써줘야 한다. (가령,  pintos --fs-disk filesys.disk -- KERNEL_COMMANDS...)

그 이후에 커맨드 라인에 -f -q 옵션을 적어줘서 파일 시스템 파티션을 포맷팅합니다. (가령, pintos SCRIPT_COMMANDS -- -f -q).

파일 시스템이 포맷팅하기 위해서 -f 옵션을 쓰고, -q 옵션은 핀토스가 포맷팅이 끝나면 바로 끝나도록 합니다. (**파일 시스템 파티션: 물리적인 디스크를 논리적인 저장영역으로 구분한것)