cedis 님의 블로그

Dave O'HallaronTiny 코드에 대입한 흐름Accept -> doit(connfd) -> Rio_readlineb -> method == "GET" -> read_requesthdrs -> parse_uri("/home.html") -> stat("./home.html") -> serve_static -> mmap -> Rio_writen(connfd, file)13-2. 동적 콘텐츠 요청 확인동적 콘텐츠는 파일을 그대로 보내는 것이 아니라, 실행 파일을 돌린 결과가 응답이 되는 경로다. 아래 요청에서 ? 뒤의 n1=15000&n2=213은 parse_uri에서 cgiargs로 분리되고, serve_dynamic에서 QUERY_STRING 환경변수로 넘어간다.curl --htt..

CSAPP 11장 공부 기록 2편소켓과 커널 내부: fd에서 NIC/DMA까지1편에서는 데이터가 컴퓨터 밖에서 frame, packet, segment로 포장되어 이동하는 그림을 잡았다. 이번 글에서는 같은 일을 컴퓨터 안쪽에서 본다. 응용 프로그램이 write(sockfd, buf, n) 한 줄을 호출하면, 운영체제와 하드웨어는 실제로 무엇을 하는가?이번 글에서 다루는 것소켓은 물리적인 구멍이 아니라 커널의 소프트웨어 객체라는 점fd, FDT, VFS, socket object가 어떻게 이어지는지socket, bind, listen, accept, connect 호출 순서CSAPP helper 함수 open_clientfd, open_listenfd, RIO 함수가 무엇을 자동화하는지TCP와 UDP의 ..

CSAPP 11장 공부 기록 1편네트워크 바깥세상: 장비, 주소, 캡슐화CSAPP 11장을 처음 읽을 때 가장 먼저 막힌 지점은 소켓 코드가 아니었다. Ethernet, bridge, router, LAN, WAN, frame, packet 같은 말이 현실 장비와 바로 연결되지 않았다. 이 글은 그 혼동을 풀기 위해, 데이터가 내 컴퓨터 밖에서 어떤 이름과 포장으로 이동하는지 정리한 1편이다.이번 글에서 다루는 것클라이언트-서버 트랜잭션이 정확히 무엇인지현실 장비 기준으로 Ethernet, hub, switch, bridge, router, LAN, WAN을 구분하는 법데이터가 TCP/IP 4계층을 내려가며 어떤 헤더를 얻는지frame, packet, segment가 왜 같은 듯 다른 말인지IP는 최종 ..

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..