이번 주는 핀토스의 마지막 주차인 파일 시스템이다. 보통 핀토스는 프로젝트 2와 3이 가장 어려운 편이고, 마지막 프로젝트 4가 쉬운 편이라고 하는데 그렇다고 만만할 정도는 아니었다... 그래도 핀토스에 대한 흐름이 어느 정도 잡혀있어서 그런지 초반에 개념을 잡고 나니 구현은 생각보다 빠르게 진행됐다. 초반에 개념 잡는 게 어려우니 오늘 포스팅은 파일 시스템의 기본 개념에 대해서 다뤄보려고 한다! Inode 먼저 핀토스가 제공하는 기본 코드에 대해서 살펴보자. 커널에서 파일이나 directory에 접근할 때 항상 inode라는 구조체를 거쳐서 접근하게 된다. inode 구조체를 살펴보자! /* In-memory inode. */ struct inode { struct list_elem elem;/* El..
핀토스 프로젝트 2의 시작은 시스템 콜부터다. 사실상 argument passing은 몸풀기... 문제는 몸풀기 수준이었던 argument passing조차도 쉽지만은 않았다는 거..! 이번 포스팅에서는 시스템 콜 중에서 파일 입출력과 관련된 시스템 콜들을 다뤄볼 예정이다. 저번에 웹 프록시 서버를 구현할 때 소켓을 파일로 추상화하여 소켓에게도 파일 디스크립터가 붙었는데, 이번에도 파일 디스크립터 개념을 사용한다. 파일 디스크립터와 관련해서는 다뤘던 포스팅이 있으니 참고하자. https://codable.tistory.com/19 [Computer System] File Descriptor File Descriptor 유닉스 시스템에서는 많은 것들을 파일로 관리한다. 정규 파일들뿐만 아니라 디렉터리, 소..
핀토스 프로젝트 1의 extra 과제이다. multi-level feedback queue scheduler의 구현인데, 일단 저번 포스팅에서 소개했던 스케줄러들과 비교해서 어떤 점이 좋은지 살펴보자. 기존 Priority Scheduler의 문제점 기존 우선순위 스케줄러는 저번 포스팅에서도 언급했다시피 우선순위가 낮은 작업이 계속해서 순서가 밀려 CPU를 얻지 못하는 Starvation 현상이 발생할 수 있다는 점이 있었다. 물론 핀토스에서 구현하는 우선순위 스케줄러에서는 priority donation도 있어 우선순위가 낮은 작업도 충분히 실행될 기회를 잡을 수 있지만, 특별히 락을 소유하지 않고 우선순위도 낮은 작업들은 이러한 조정도 받지 못할 수 있다. 이로 인해 task들의 평균 대기 시간이 길..
드디어 대망의 핀토스다..! 프로젝트 1은 스레드에 관한 내용이다. 좀 더 정확히 짚어서 말하자면 스케줄링 알고리즘 구현이라고 볼 수 있겠다. CPU Scheduling 우리가 사용하는 컴퓨터에서는 여러 개의 프로그램들이 동시에 돌아가고 있다. 좀 더 엄밀히 말하면 동시에 돌아가는 것처럼 보이는 것이다. 사실은 한개의 프로그램만이 하나의 CPU 코어를 사용할 수 있고, 사용 주기가 굉장히 빠르게 교체되기 때문에 우리 눈에는 프로그램들이 동시에 돌아가는 것처럼 보이는 것이다. 여기까지는 우리가 컴퓨터를 보는 입장에서의 설명이었고, 프로그램의 입장에서는 CPU를 마치 자기 자신만이 소유한 것처럼 사용할 수 있게 하는 것이 CPU Scheduling의 목표이다. 현재 프로그램이 디스크에 접근하거나, 키보드의 ..
