거북이의 쉼터

지난 시간에 매뉴얼은 다 봤으니 설계를 해 보자. VM_FILE에 저장을 해야 하는 것들을 생각해보면: 인자로 들어가는 type (마커가 있을지도 모르기에) swap in/out을 하기 위해 해당 페이지가 어디에서 기원했는지를 알려주는 정보 (file 포인터, ofs 등) nullbyte 패딩을 위한 길이 해당 인자들은 struct file_page에 넣어주고 관리할 것이다. 문제는 해당 인자들을 넘기려면 aux에서 넘겨야 하기 때문에 file_backed_initializer에서는 해줄 것이 마땅히 없다. 중요한 것은 lazy_load_segment와 유사하게 aux가 넘겨지는 init을 구현해주는 것이다. 아직도 initializer 계열 함수에 kva가 들어가 있는 이유를 모르겠다. 왜지? swap..

드디어 VM_UNINIT과 VM_ANON의 좁고 편협한 사고에서 벗어나 VM_FILE을 다루게 되는 mmap이다. 보이는 것처럼 나는 아주 "절거워"질 예정이다. 지금 여기까지 해온 사람들에게는 익숙하겠지만 mmap은 파일의 내용을 메모리 상에 올려 입출력을 빠르게 해줄 수 있는 기법이다. 구현할 mmap의 형태는 다음과 같으며, void *mmap (void *addr, size_t length, int writable, int fd, off_t offset); addr에 주어진 length 만큼의 공간에 fd에 대응되는 파일의 offset에 해당하는 내용을 매핑한다. 이 때, 매핑된 해당 페이지의 쓰기 권한은 writable을 따른다. 주어진 addr은 반드시 page-aligned 되어 있어야 하며..

보호되어 있는 글입니다.

현타 오는게 지금까지 뭔가 많이 한 거 같은데 결과는 프로젝트 2의 복원에 불과하다. ㅋㅋㅋㅋ.... 이제 좀 본격적으로 프로젝트 3의 내용을 좀 짜보자. 이전 포스팅에서 조금씩 언급해온 stack growth를 구현하는 것이 해당 소주제에서 이뤄야 할 과제이다. pintos는 여지껏 stack은 단 한 개의 페이지로만 운영되어 왔다. 프로세스를 로딩할 때 argument가 들어갈 페이지를 제외하고는 할당해주지 않았었다. 그러나 이제부터는 stack의 공간을 추가적으로 할당할 필요가 있으면, 해당 페이지를 할당해주어야 한다. stack 공간을 할당할 때, 일반적인 실행 파일이 로딩되는 것과 다른 점은, stack 주소는 spt에 struct page로서 매핑이 되어 있음이 보장되어 있지 않다는 것이다. ..