cedis 님의 블로그

운영체제 · Pintos · Project 2 · Week 10WIL 10주차: Pintos Project 2에서 배운 것은 syscall이 아니라 경계였다Pintos Project 2를 진행하며 배운 문제해결, 설계, 구현, 협업 흐름과 정글 핵심 10대 역량 달성도를 정리한다.이번 주 Pintos Project 2는 syscall을 많이 외우는 주가 아니었다. 유저가 커널에게 무언가를 요구할 때, 그 요구를 어디까지 믿고 어디서 끊어야 하는지 계속 확인한 주였다.이번 주를 한 줄로 정리하면Week 10커널과 유저, 부모와 자식, 파일 원본과 fd 번호 사이의 경계를 코드로 그어 본 주였다.이번 주 학습 흐름1. 출력이 안 보임args를 보려면 `write` syscall도 살아야 했다.2. 주소를 못..

운영체제 · Pintos · Project 2 · Week 10Pintos Project 2 최종 구현 정리: main branch 코드가 만들어지는 흐름최신 main branch 기준으로 Project 2 구현을 다시 조립한다. 따라 만들 수 있도록 구조체, syscall, fd, fork, wait 흐름을 블록 단위로 정리했다.이 글의 목표이 글은 발표용 세계관 글이 아니라, 최종 main branch의 Project 2 구현을 따라 조립하기 위한 기술 지도다. 코드 전체를 무작정 붙이는 글이 아니라, 어떤 블록이 어떤 테스트 요구를 해결하는지 기준으로 정리한다.0. 최종 main 기준 결과최신 main 기준 결과는 전체 95개 중 85개 통과다. Project 2 기본 userprog는 64개 중 ..

운영체제 · Pintos · Project 2 · Week 10Pintos Project 2 발표 회고: 핀토스 제국은 어떻게 신민을 통제했는가정글 10주차 발표 자료를 바탕으로 Project 2를 하나의 제국 행정 시스템으로 다시 정리했다.이번 글에서 다루는 것Project 2 발표 자료를 하나의 제국 세계관과 행정 시스템으로 다시 읽기process, syscall, fd, fork/wait를 각각 신민·검문소·열람증·생산 공장으로 연결하기85/95 통과라는 결과를 미완성 제국의 행정 지도로 정리하기Pintos User Process Revolution 발표 표지1. x86 우주, QEMU 행성, Pintos 제국이번 발표에서 우리는 Pintos Project 2를 기능 목록으로 설명하지 않았다. 하나..

Pintos Project 2 분업 기록fork 파트는 어디까지 혼자 만들 수 있고,어디부터 팀 코드와 맞물릴까팀 브랜치를 합친 뒤 내 담당은 fork 쪽으로 정리됐다. 처음에는 fork 말고 다른 작업을 먼저 할 수 있을지 봤지만, fd table, wait, deny write가 서로 물려 있어서 임시 코드로 밀어붙이면 나중에 더 꼬일 가능성이 컸다. 그래서 이번 글은 fork 엔진 자체를 코드 흐름으로 다시 읽고, 다음 연결 지점을 표시하는 데 집중한다.이 글의 완성 기준읽는 목표이 글만 보고 fork 관련 코드 블록을 기존 브랜치에 같은 구조로 옮길 수 있어야 한다.핵심 흐름SYS_FORK -> process_fork() -> thread_create() -> __do_fork() -> dupli..

Pintos Project 2 중간 과정 기록 Argument Passing 이후,choihyunjin_fork 브랜치에서 구조가 어떻게 바뀌었나 args 테스트가 어느 정도 움직이기 시작하자, 다음 질문은 “통과했나?”가 아니라 “이 코드 위에 다음 기능을 계속 얹어도 되나?”가 되었다. 팀 회의 후 기준을 choihyunjin_fork 브랜치로 옮기면서, 이전 구현과 새 구조의 차이를 코드 블록 단위로 다시 읽어보았다. 이 글을 쓰는 이유 처음에는 args-single을 통과시키는 것이 급했다. 그래서 문자열을 자르고, stack에 올리고, 레지스터를 맞추고, 부모가 먼저 끝나지 않게 하는 장치까지 ..

운영체제 · Pintos · Project 2 User Programs · 1편Pintos Argument Passing: 프로그램 실행 인자를 argc와 argv로 넘기기Project 1에서는 thread를 언제 재우고, 어떤 순서로 깨우고, priority를 어떻게 다룰지 봤다. Project 2로 넘어오면 질문이 바뀐다. 이제 커널은 단순히 thread를 돌리는 것을 넘어서, 유저 프로그램을 실행 가능한 형태로 시작시켜야 한다. 이번 글은 그 첫 단계인 Argument Passing을 정리한다.이번 글에서 다루는 것왜 args-single onearg 같은 문자열을 그냥 실행 파일 이름으로 쓰면 안 되는지실행 파일 이름과 프로그램 인자를 어떻게 분리했는지user stack에 문자열, argv 포인터..

크래프톤 정글 · Week 9 WIL · Pintos Project 1 ThreadsPintos, 완성된 교향곡에서 베이스를 찾는 과정9주차가 끝났고, 내 손에는 Pintos 글 3편과 로드맵, 테스트 기반 구현 가이드가 남았다.숫자보다 중요한 건 그 과정에서 내가 운영체제 코드를 읽는 방식이 바뀌었다는 점이다.이번 주를 한 줄로 정리하면이번 Pintos 프로젝트는 완성된 교향곡 속에서 흐름을 이해하기 위해 베이스를 찾아가는 과정이었다.처음에는 모든 파일과 함수가 동시에 울리는 것 같았다. 어느 함수가 주선율인지, 어떤 interrupt가 박자를 잡는지, 어떤 테스트가 낮게 깔린 베이스처럼 전체 흐름을 붙들고 있는지 보이지 않았다. 이번 주는 그 소음을 한 줄씩 분리해서 듣는 시간이었다.이번 주 목표 3..

운영체제 · Pintos · Project 1 Threads · 3편Pintos MLFQS: nice, recent_cpu, load_avg로 Project 1 마무리하기1편에서는 alarm-priority를 통해 ready list의 priority 정렬을 봤고, 2편에서는 기본 Priority Scheduler와 donation을 정리했습니다. 이번 3편은 Project 1 Threads의 마지막 축인 MLFQS(Multi-Level Feedback Queue Scheduler)입니다. 핵심은 단순합니다. 이제 priority를 사람이 직접 정하는 것이 아니라, scheduler가 수식으로 계속 다시 계산합니다.이번 글에서 다루는 것MLFQS가 기본 Priority Scheduler와 어떻게 다른지n..

운영체제 · Pintos · Project 1 Threads · 2편Pintos 기본 Priority Scheduler: waiters 정렬과 priority donation 구현하기1편에서는 alarm-priority를 통해 ready list를 priority 순서로 유지해야 한다는 점을 봤습니다. 이번 글은 그 다음 단계입니다. 깃북이 요구하는 기본 Priority Scheduling을 기준으로 semaphore, condition variable, lock donation까지 연결해서 정리합니다.이번 글에서 다루는 것깃북의 Priority Scheduling 요구사항을 한글로 다시 정리깃북 문장을 테스트와 코드 수정 지점으로 바꾸는 첫삽FIFO 대기열을 priority-aware 대기열로 바꾸는 ..

운영체제 · Pintos · Project 1 Threads · 1편Pintos alarm-priority: ready_list 우선순위 정렬로 출력 순서 맞추기이번 글은 Pintos Project 1 전체가 아니라 Alarm 테스트 중 alarm-priority에서 드러난 우선순위 문제를 다룹니다. timer_sleep()과 busy waiting은 배경으로만 보고, 실제 코드 분석은 thread.c의 ready list 정렬 수정에 맞춥니다.이번 글에서 다루는 것Alarm Clock 테스트가 thread 상태 전이를 어떻게 확인하는지alarm-priority가 왜 ready list 정렬 문제로 이어지는지실제로 반영한 thread_priority_more, thread_unblock(), thread..