[Week10] WIL - Pintos_Project 2

벌써 Pintos 과정의 절반이 지나갔다.
정글에 적응하고 사람들과 가까워지다 보니 시간이 더욱 빠르게 흘러가는 것 같다. 하지만 공부해야 할 것은 여전히 많고, 한 주라는 시간은 생각보다 짧다. 그래서 지금 이 시점에는 ‘무엇을 가장 우선해야 하는가’를 판단하는 것이 중요하다고 느꼈다.
지난 피드백 이후, 팀원들과 이번 주에 가장 가치 있게 가져가야 할 목표가 무엇인지 진지하게 고민해보았다. 제한된 시간 안에 모든 것을 완벽하게 챙기는 것은 현실적으로 어렵다고 판단했고, 결국 우리는 ‘진행 속도가 느린 팀원을 함께 끌어올리는 것’을 가장 중요한 우선순위로 정했다.
AI를 활용해 충분히 이해하지 못한 상태로 테스트 케이스만 통과시키는 것은 큰 의미가 없다고 생각한다. 이번 주는 팀원들과 최대한 많이 소통하고 협력하면서, 단순한 결과보다도 서로가 제대로 이해하고 성장할 수 있는 시간을 만들어보고자 한다.

 

핵심 역량 평가

역량	달성도	목표
문제해결	90%	system-call-fork 테스트 전까지 모든 테스트 케이스를 통과한다.
read/write를 제외한 테스트까지는 통과했다.
설계	90%	코드를 작성하기 전에, 지금 구현하려는 코드가 어떤 기능의 일부이며 무엇을 해결하기 위한 것인지 먼저 명확하게 설계하려고 한다.
메서드 기능을 구현하는 것 자체에만 초점을 두지 않고, 프로젝트 전체 흐름을 이해하면서 코드 구조를 설계했다.
구현	100%	Pintos의 기존 코드 흐름을 해치지 않으면서 테스트케이스가 통과되도록 구현한다.
기존 코드 구조를 해치지 않고, 알맞게 로직을 수정/추가 하였다.
품질	100%	통과되는 테스트 케이스라도 정말 문제가 없는지 고려해본다.
bad-ptr같이 검증되지 않은 주소에 접근하는 테스트에 대해, 단순히 통과 로직뿐만 아니라 어떤 상황에서도 사용할 수 있도록 엣지 케이스를 고려하여 안정성을 확보하였다.
유지보수	90%	복잡한 로직은 함수로 분리하고, 코드 의도를 짧은 주석으로 남겨 팀원이 이해하기 쉽게 작성한다.
load 함수 내에서 파싱, stack_push를 하는 것이 가독성이 떨어지고 역할 분리가 되지 않는다고 판단하여 별도의 함수로 분리하였다.
협업	100%	진행 속도가 느린 팀원들을 함께 끌어올려, 학습 과정에서 소외되는 사람이 없도록 한다.
코어타임을 학습 진행속도가 느린 팀원 기준으로 진행하며, 모두가 만족할 수 있는 동료 학습을 진행하였다.
태도	100%	테스트 실패를 단순 오류로 넘기지 않고, Pintos 내부 동작 원인을 끝까지 추적하며 해결하는 집요함을 기른다.
매핑되지 않은 주소에 접근했을 때 생기는 문제를 파악하기 위해 끝까지 추적하였다.
AI 활용	80%	AI를 단순 코드 생성 도구가 아니라, Pintos 개념 이해, 테스트 실패 원인 분석, 디버깅 방향 설정, 코드 리뷰 보조 도구로 활용하여 생산성을 높인다.
코드를 직접 생성하는 일은 없도록 하였고, 개념 이해, 테스트 실패 원인 추적, 디버깅 방법 등에만 활용하였다.
학습 민첩성	100%	낯선 OS 개념을 빠르게 이해하고 구현에 즉시 적용한다.
Pintos의 모든 개념을 이해하려 하지 않고, 핵심 부분만 학습하고 바로 구현에 뛰어들었다.

 

❓ Weekly Problem : 매핑되지 않은 주소 접근과 Page Fault

open, create 테스트에서 파일 주소에 대한 검증을 안했을 때,

open-bad-ptr.c와 create-bad-ptr.c 테스트가 통과하지 못하는 문제가 있었다.

 

🚩 두 테스트가 공통적으로 [주소 0x20101234]에 대한 접근을 시도한다는 것을 알 수 있다.

이 주소에 접근하는 것이 뭐가 문제가 되는 것인지 알기 위해, 잠깐 Pintos 메모리 레이아웃에 대해 정리해보았다.

 

Pintos 메모리 레이아웃

- 커널 공간은 0x8004000000 주소부터 매핑이 되어있다.

- 파싱한 문자열을 유저 모드에 넘길 때 사용했던 USER_STACK은 0x47480000 주소부터 매핑이 된다.

- 디스크에서 찾은 ELF 파일의 PT_LOAD 정보는 0x400000 주소부터 매핑이된다.

➡️ 접근하려고 하는 0x20101234는 아직 매핑이 되지 않은 영역이다!

 

매핑하지 않은 주소 접근의 결과

매핑하지 않은 주소에 접근하는 것이 왜 테스트 실패까지 이어지는지 알아보기 위해,

실제 문제가 생겼던 open 함수의 로직을 트래킹해보며 실제 원인을 파악해보았다.

1️⃣ 구현한 open 메서드에서 filesys_open 메서드 호출

 

2️⃣ 디렉토리 엔트리 탐색 시도

- 파일 시스템은 [파일 이름 ↔️ 디스크 위치] 매핑 정보를 디스크의 특정 영역(루트 디렉토리 섹터)에 테이블 형태로 저장.

- 이 테이블이 저장된 디스크 섹터를 열어 탐색을 시작한다.

 

3️⃣ 디렉토리 엔트리를 순회하며 일치하는 파일 이름이 존재하는지 탐색

- 테이블의 각 항목(엔트리)을 하나씩 읽으며, 항목에 기록된 파일 이름과 찾으려는 파일 이름을 문자열 비교

 

4️⃣ 매핑되지 않은 주소에 접근하여 바이트를 읽기 위해 역참조

- 문자열 비교를 위해 커널이 0x20101234에 실제로 접근해 첫 번째 바이트를 읽으려 시도

 

🔎 MMU의 pml4 테이블 탐색
- CPU는 가상 주소를 물리 주소로 변환하기 위해 4단계 페이지 테이블(PML4 -> PDPE -> PED -> PTE)을 순서대로 탐색
- 이 주소는 한 번도 물리 메모리에 매핑된 적이 없으므로, 이 주소에 해당 페이지가 없다는 것을 확인
- 하드웨어가 탐색을 중단하고 Fault 주소를 CPU 내부 레지스터(CR2)에 기록
- 인터럽트 14 발생!

 

exception.c

5️⃣ 인터럽트 번호에 대한 핸들러 함수 등록

- exception.c에 각 인터럽트에 대해서 핸들러 함수를 등록해두었다.

- 14번 인터럽트가 발생하면, page_fault 메서드를 호출한다.

 

6️⃣ page_fault 메서드 내에서 kill 메서드 호출

 

7️⃣ kill 메서드 내에서 현재 레지스터의 권한 레벨을 확인한다.

- 만약 유저 코드에서 발생한 인터럽트면, 프로세스를 종료한다.

- 만약 코드 코드에서 발생한 인터럽트면, PANIC 메서드를 호출한다. 

 

해결 방안 - pml4_get_page 메서드 사용

pml4_get_page는 유저 가상 주소에 대응하는 커널 가상 주소를 반환하며, 매핑이 존재하지 않으면 NULL을 반환한다.
매핑이 없는 주소에 접근하면 페이지 폴트가 발생하므로, 반환값이 NULL인 경우 exit을 호출해 프로세스를 즉시 종료하도록 처리하였다.

---

10주차 회고

이번 주차는 단순한 진도보다, 팀원 모두가 내용을 이해하고 함께 넘어가는 과정에 더 큰 의미를 두었다.

진행도가 낮은 팀원의 코드를 함께 보며 의견을 나누는 시간을 가졌는데, 단순히 정답 코드를 공유하는 것이 아니라, 각자가 어떤 흐름으로 구현을 시도했는지 이야기하고 서로의 관점을 맞춰가며 이해를 도왔다. 그 결과, 팀원 모두가 Argument Passing의 동작 원리와 구현 흐름을 확실히 이해한 채 다음 단계로 넘어갈 수 있었다.

이번 경험을 통해, 잘하는 사람이 일방적으로 설명해주는 것이 팀 전체의 이해로 곧바로 이어지는 것은 아니라는 점을 확실히 느꼈다. 지난주에는 내 코드를 기준으로 merge를 진행하며 개념과 코드를 설명하는 방식이었다면, 이번에는 각자가 직접 고민하고 구현한 내용을 중심으로 함께 토론하는 방식에 가까웠다. 그리고 실제로 이번 주차가 팀원 전체의 이해도 면에서 더 좋은 결과를 만들었다고 느꼈다.

특히 스스로 구현에 성공해 테스트를 통과한 팀원의 반응을 보며, 단순히 빠르게 결과를 만드는 협업보다 각자의 이해와 성장을 이끌어내는 협업이 훨씬 중요하다는 것을 체감할 수 있었다. 동시에, 한 사람이 끌고 가는 수직적인 협업 방식에는 분명한 한계가 있다는 점도 다시 한번 느낄 수 있었던 주차였다.