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를 열면 이미 완성된 운영체제 일부처럼 보인다. 그래서 함수 이름을 위에서부터 읽고, 구조체를 외우고, 주석을 따라가려 했다..

Project 4 File System 시리즈 4편FAT, 하위 디렉터리, 디렉터리 fd syscall까지 연결한 뒤 마지막으로 붙인 기능은 symbolic link였다. symlink는 대상 파일을 복사하지 않는다. 작은 inode 하나에 target path를 저장하고, open 과정에서 그 path를 다시 해석한다.핵심부터 말하면이번 구현에서 symlink inode는 실제 파일 데이터를 갖는 대신 target 문자열을 metadata로 저장한다. open("link")가 들어오면 path resolver가 link inode를 발견하고, target path로 이어서 다시 resolve한다. 순환 링크를 막기 위해 최대 깊이는 8로 제한했다.symlink 해석 흐름입력/a/link/filelink..

Project 4 File System 시리즈 3편하위 디렉터리까지 만들었다면 다음 문제는 user program이 그 디렉터리를 어떻게 다루느냐이다. Project 4는 directory도 open()으로 열고, fd를 통해 readdir, isdir, inumber를 호출하게 한다.핵심부터 말하면이번 구현에서는 fd table을 크게 갈아엎지 않고, 디렉터리 inode도 struct file로 열었다. 대신 file_is_dir(), file_readdir(), file_inumber() 같은 wrapper를 추가해서 syscall 계층이 같은 fd 경로로 파일과 디렉터리를 구분하게 했다.fd에서 디렉터리 entry까지user fd정수 fdfd tablefd → file handlestruct fil..

Project 4 File System 시리즈 2편1편에서 FAT와 파일 확장을 만들었다면, 이번에는 파일 이름을 찾는 방식 자체를 바꾼다. Project 4의 디렉터리 테스트는 더 이상 모든 파일이 root 아래에 있다고 봐주지 않는다.핵심부터 말하면기존 파일 시스템은 파일 이름 하나를 root directory에서만 찾으면 됐다. Project 4에서는 /a/b/c, ../x, 현재 작업 디렉터리, ., ..까지 처리해야 한다. 그래서 파일 생성과 삭제도 “부모 디렉터리 찾기 + 마지막 이름 처리”로 나누었다.경로 해석 흐름입력../tmp/a시작점절대경로면 root, 아니면 cwdtoken 순회.., tmp, a결과마지막 inode 또는 부모 dir1. thread가 현재 작업 디렉터리를 가져야 한다..

Pintos Project 3 · Copy-on-Write앞선 VM 글에서는 SPT, lazy loading, stack growth, frame table, swap, mmap까지 정리했다. 이번 글은 Project 3의 Extra인 COW(Copy-on-Write)를 다룬다. 핵심은 단순하다. fork 때 페이지를 바로 복사하지 않고, 부모와 자식이 같은 frame을 읽기 전용으로 공유하다가, 누군가 write를 시도하는 순간 진짜 복사한다.검증 기준이 글은 COW가 들어간 Pintos VM 코드를 별도 복사본에서 다시 빌드하고, COW 공개 테스트를 직접 실행한 결과를 기준으로 작성했다. 추가로 기존 최종 체크 로그에서 전체 VM 테스트 통과 기록도 확인했다.fresh 검증 · tests/vm/co..

Project 4 File System 시리즈 1편Project 3까지 완성된 코드 복사본 위에서 Project 4를 구현했다. 이번 글은 그중 첫 번째 축인 FAT 기반 파일 확장을 실제 코드 기준으로 정리한다.핵심부터 말하면기존 Pintos 파일 시스템은 파일이 디스크에서 연속된 sector에 저장된다고 보는 구조였다. Project 4에서는 파일이 커질 수 있고, 디스크 빈 공간이 항상 연속되어 있다는 보장도 없다. 그래서 inode에는 “첫 cluster”만 저장하고, 다음 cluster는 FAT 테이블을 따라가도록 바꿨다.이전 구조의 한계inode가 시작 sector와 길이만 알면 파일 위치를 계산할 수 있었다. 하지만 이 방식은 파일 확장과 조각난 빈 공간에 약하다.바뀐 구조inode는 첫 c..