The Story of Joon
Pintos: 프로젝트 시작 전 팁 본문
※ Pintos 기본 세팅: http://topology-blog.tistory.com/2
핀토스를 학교에서 시켜서 하게 된다면 아마 학교에서 교수님이나 조교님 등이 도움을 많이 주시겠지만, 미리 해본다든가 하는 이유로 따로 하는 경우도 있을 것이다. 핀토스와 같은 프로젝트를 해본 경험이 있다면 잘 헤쳐나가겠지만, 그러지 않은 경우 처음에 많은 어려움을 겪게 될 가능성이 높다. 필자 역시 그랬다. 그래서 이 포스트는 그러한 사람들, 그리고 필자 본인을 위한 포스트이다.
프로젝트별 팁은 포스트를 따로 남긴다. 여기서는 프로젝트를 전반적으로 어떤 점을 유의해야 하는지에 대한 필자의 생각을 다룬다. 사람마다 의견은 다를 수 있으며, 여기에 쓰인 내용은 그저 참고용으로 봐주셨으면 좋겠다.
1. Project Documentation을 꼼꼼하게 읽자.
핀토스를 설치까지 했다면 당연히 봤겠지만, 여기에 스탠퍼드 대학에서 제공하는 documentation이 있다(pdf 파일도 있다). 이곳에는 설명이 자세히 잘 되어있고, 핀토스 코드의 전반적인 요약도 있다. 그러나 무엇보다 가장 중요한 것은 프로젝트별로 항목이 있는 Background, Requirement이다. 여기에 있는 내용을 모두 이해해야 코딩을 제대로 할 수 있으며, 그렇지 않으면 결함이 생겨 테스트가 fail하거나 아예 핀토스가 작동하지 않을 수도 있다.
때로는 FAQ도 도움이 되기도 한다. 각 프로젝트 FAQ 첫 부분에는 Reference solution에 대한 정보가 나와있는데, 각 코드가 어느 정도 수정되었는지 알 수 있다. 이것은 무엇을 해야 할지 갈피를 못 잡을 때 (프로젝트 3을 하게 된다면 느낄 것이다) 많은 도움이 된다. 그러나 여기에 너무 얽매이지 않는 것이 좋다. 핀토스 도큐에 있는 아래의 문장을 보라.
The reference solution represents just one possible solution. Many other solutions are also possible and many of those differ greatly from the reference solution. Some excellent solutions may not modify all the files modified by the reference solution, and some may modify files not modified by the reference solution.
부록 형태로 나와있는 Reference Guide는 처음부터 다 읽을 필요는 없으나, 프로젝트를 하다 보면 자연스럽게 읽게 될 것이다. 여기에는 이미 구현을 해놓은 hash table과 같은 자료구조라든지, page table이나 thread structure와 같이 우리를 위해 구현을 해준 부분에 대한 설명이 나와있다. 아래에서도 이야기하겠지만, 이미 구현되어있는 부분에 대해서는 어셈블리 코드가 아닌 이상 코드를 직접 읽어보는게 가장 좋다.
프로젝트 1에서 4.4BSD Scheduler를 구현하게 된다면 레퍼런스 가이드를 읽게 될 것이다.
2. 코드를 읽는 시간을 아까워하지 말자.
핀토스를 열어봤다면 이미 봤겠지만 정말 많은 부분이 내부구현이 되어있다. 그래서 파일도 어마어마하게 많다. 일례로 프로젝트 1에서 주로 활동하게 될 threads 폴더에는 헤더파일을 제외해도 무려 11개의 파일이 있다. 처음에 이것을 보면 설마.. 이것들을 다 읽어봐야 하겠어..? 라고 생각할 수도 있다. 그렇다. 결국 싫어도 몇몇 어셈블리 파일을 제외하고는 대부분의 코드를 읽어보게 될 것이다.
남의 코드를 읽고 그걸 또 이해하는 것은 결코 쉬운 일은 아니다. 처음 코드를 읽으려고 그 자체가 매우 귀찮다. 그리고 include하는 파일도 매우 많기 때문에 다 읽는 것은 몹시 힘들다. 그러나 핀토스에 대한 감을 잡는 것은 어떤 프로젝트를 하든 매우 중요하기 때문에, 최소한 핀토스 핵심파일인 thread.c는 모두 읽어보는 것을 강력하게 권유한다.
그래도 핀토스는 한 사람이 작업한 것처럼 보일 정도로 코딩 스타일이 일관성 있고, indentation도 잘 되어있으며 주석도 꼼꼼하다. 그렇다고 주석만 읽어보는 것은, 주석에 코드의 모든 내용을 다 담을 수는 없기 때문에 추천하지 않는다.
코드를 읽다 보면 가끔 c 파일에서 인라인 어셈블리 코드(asm, asm volatile 등)를 만날 때가 있다. 인라인 어셈블리는 프로젝트할 때 직접적으로 쓸 일도 없고 이해하지 않아도 되지만, OS의 작동 방식을 이해하는 데 도움이 될 때가 있다. 예를 들면, 80x86 아키텍쳐의 특정 레지스터에 접근하는 일은 c 코드로는 할 수 없다. 프로젝트 3에서 만나게 될 page table의 위치를 MMU (Memory management unit)에게 알려주기 위해 OS는 CR3 (Control register 3)에 주소값을 넣어준다. 반대로 page fault가 났을 때 MMU는 fault를 일으킨 주소값을 CR2에 넣어준다. 이 부분은 다음과 같이 구현이 되어있다.
/* In userprog/pagedir.c */ void pagedir_activate (uint32_t *pd) { /* ... (전략) ... */ asm volatile ("movl %0, %%cr3" : : "r" (vtop (pd)) : "memory"); }
/* In userprog/exception.c */ static void page_fault (struct intr_frame *f) { /* ... (전략) ... */ asm ("movl %%cr2, %0" : "=r" (fault_addr)); /* ... (후략) ... */ }
3. 코딩 스타일을 깔끔하게 하자.
핀토스같이 코딩할 양이 많은 프로젝트는 코딩스타일을 더럽게 하는 것은 좋지 않다. 혼자 대충대충 하고 치울 것이 아니면 주석도 달고 indent도 일관성 있게 하자. 특히 프로젝트를 같이 하는 사람이 있는 경우에 메이트로부터 컴플레인이 들어올 수도 있다...
또한 프로젝트를 하다 보면 처음에 생각지 못한 변수들이 계속 나오기 마련이다. 그러다보면 코드를 좀 많이 뜯어고쳐야 할 경우가 생길 수 있는데, 주석 처리 등을 제대로 해놓지 않으면 본인조차도 무슨 생각으로 이런 식으로 짰는지 모를 때가 있다. 가장 좋지 않은 케이스는 왜 넣었는지 모르겠어서 코드를 지웠더니 안돌아가고, 또 한참 생각하다 자신이 그렇게 짰던 이유를 깨닫고 다시 넣는 경우다. 주석 넣는데 시간이 그렇게 많이 걸리지도 않은데 그 시간 아끼려다가 시간 더 날려먹는다.
핀토스 플젝 진행 시 유의해야 할 공통적인 사항들을 이렇게 세 가지로 간단하게 정리해 보았다. 이 글을 읽는 분들은 대부분 핀토스를 시작했거나 이미 시작한 분들일 것 같다. 핀토스 화이팅. ㅎㅎ.
'Computer Science > 운영체제' 카테고리의 다른 글
Pintos: 기본 세팅 (0) | 2017.02.02 |
---|