cedis 님의 블로그

Pintos 완주 후 다시 읽기스레드, 프로세스, VM, 파일 시스템을 한 요청 흐름으로 묶어 Pintos 전체 지도를 만든다.이 글에서 다루는 것앞선 글들이 각각 interrupt, process, VM, file system을 따로 보았다면, 이번 글은 하나의 요청이 그 층들을 어떻게 지나가는지 본다. 완성 후 다시 읽기의 목적은 바로 이 전체 지도를 갖는 것이다.user program의 write 요청이 kernel로 들어오는 길user pointer 검증 중 VM이 개입하는 지점fd table에서 file 객체를 찾고 inode/FAT까지 내려가는 흐름완주 후 코드를 다시 볼 때의 읽기 순서1. 요청 하나를 끝까지 따라가면 구조가 보인다예를 들어 user program이 write(fd, buff..

Pintos 완주 후 다시 읽기Project 4의 path, directory, symlink, inode, FAT를 하나의 번역 흐름으로 다시 읽는다.이 글에서 다루는 것Project 4는 파일 시스템 기능을 많이 추가한다. 하지만 완성 후 다시 보면 핵심 질문은 하나다. user가 준 문자열 경로를 어떻게 실제 디스크 조각까지 연결할 것인가.상대/절대 경로와 현재 디렉터리directory entry와 inodesymlink 재해석파일 grow와 FAT chain1. 경로는 문자열이 아니라 탐색 계획이다/a/link/file 같은 문자열은 파일 자체가 아니다. 루트에서 시작할지 현재 디렉터리에서 시작할지 정하고, 토큰을 하나씩 lookup하면서 inode를 찾아가야 한다.경로 해석 흐름1path가 /로..

Pintos 완주 후 다시 읽기SPT, lazy loading, stack growth, mmap, COW를 page fault 처리 흐름으로 묶어서 다시 읽는다.이 글에서 다루는 것처음 page fault를 보면 잘못된 메모리 접근으로만 느껴진다. 하지만 Project 3을 끝내고 보면 page fault는 VM이 미뤄둔 일을 실제로 처리하는 입구이기도 하다.SPT가 왜 PML4와 별도로 필요했는지lazy page, stack growth, COW가 page fault에서 어떻게 갈라지는지mmap과 swap이 왜 page 종류별 연산으로 분리되는지1. PML4는 현재 매핑만 알고, SPT는 의도를 기억한다PML4는 현재 어떤 가상주소가 어떤 물리 프레임에 연결되어 있는지에 가깝다. 그런데 lazy lo..

Pintos 완주 후 다시 읽기Argument Passing부터 wait, fork, fd table까지를 하나의 process 상태로 다시 연결한다.이 글에서 다루는 것Project 2를 처음 풀 때 Argument Passing은 문자열을 stack에 넣는 문제처럼 보였다. 하지만 뒤로 갈수록 그것만으로는 부족했다. 프로그램은 파일 하나가 아니라, 커널이 관리하는 여러 상태의 묶음이었다.실행 명령이 user stack의 argc/argv로 바뀌는 과정syscall이 user mode 요청을 kernel mode 작업으로 바꾸는 과정wait, fork, fd table이 왜 process 구조의 일부가 되어야 했는지1. 실행 파일 이름과 실행 인자는 분리되어야 했다명령줄 args-single onear..

Pintos 완주 후 다시 읽기스레드, 알람, 시스템콜, page fault를 따로 외우기보다 커널로 들어오는 입구부터 다시 읽어본다.이 글에서 다루는 것Pintos를 처음 볼 때는 파일이 너무 많아서 위에서부터 읽기 쉽다. 하지만 완성하고 다시 보면 흐름은 함수 선언 순서가 아니라 이벤트가 커널로 들어오는 순서로 열린다.timer interrupt가 시간과 스케줄링을 어떻게 움직이는지syscall과 page fault도 같은 관점에서 어떻게 읽히는지테스트 케이스가 왜 단순 채점표가 아니라 흐름을 확인하는 악보처럼 보였는지1. 처음의 실수: 코드를 책처럼 읽으려 했다처음 Pintos를 열면 이미 완성된 운영체제 일부처럼 보인다. 그래서 함수 이름을 위에서부터 읽고, 구조체를 외우고, 주석을 따라가려 했다..