회고 어제 새벽 3시까지 동료 코드를 봐주다가 잠들었다. 그리고 아침 7시에 운동을 다녀왔다. 죽을 것 같았지만, 편의점에서 1+1 행사 중인 에너지 음료를 마시고 힘을 낼 수 있었다. 가슴 운동을 열심히 했다. 오늘은 프로젝트 3의 두 번째 파트인 Anonymous Page를 구현했다. 깃북을 읽고 개념을 공부하고 구현에 들어갔다. 익명 페이지라는 개념이 생소해서 이해하기 어려웠다. 이 파트에서 주요 구현 이슈는 익명 페이지보다는 lazy loading이다. 필요 시점까지 메모리의 로딩을 지연시키는 방식이다. 기존의 핀토스는 프로그램 로드 시에 모든 정보를 메모리에 로딩하지만, 이 파트에서 lazy loading를 구현하면서 프로그램 실행 초기에 필요한 자원을 모두 로드하지 않고 필요한 시점에 로드하면..
x86-64 기반 Pint OS 프로젝트 2의 System Calls를 구현하기 위해 공부한 개념을 정리한다. 파일 시스템 콜 파일 조작을 위한 인터페이스를 제공한다. Pint OS - Project 2(System Calls)에서 구현해야 할 파일 관련 시스템 콜은 다음과 같다. read 정의 int filesize (int fd, void *buffer, unsigned size); 열린 파일 'fd'에서 'size' 만큼의 바이트를 읽고 'buffer'에 저장한다. 실제로 읽은 바이트 크기를 반환하고, 실패했다면 -1을 반환한다. fd가 표준 입력(0)일 때는 input_getc() 함수를 사용해서 키보드 입력을 받는다. 락 include/userprog/..
발생 프로젝트 2를 구현한 후 multi-oom을 제외한 모든 테스트 케이스에서 pass했다. 여기서 특이한 것은 pass 여부가 가상 환경 사양에 따라 갈린다는 점이었다. 도커로 로컬 노트북으로 돌린 나의 경우에는 multi-oom을 통과하지만, git clone으로 받아서 AWS에서 돌린 동료들은 전부 FAIL이 뜬다. 여기서 또 신기한 점은 AWS의 t2.large 서버에서 테스트해본 동료는 또 pass했다 ㅋㅋ. 아무래도 가상 환경의 메모리 용량에 따라 multi-oom이 터지는 걸로 추정된다. 다른 동료의 코드와 한참을 비교해보다가 동료가 해결해주었다. 솔루션 tid_t process_fork (const char *name, struce intr_frame *if_) { ... if (chil..
x86-64 기반 Pint OS 프로젝트 2의 System Calls를 구현하기 위해 공부한 개념을 정리한다. 파일 시스템 콜 파일 조작을 위한 인터페이스를 제공한다. Pint OS - Project 2(System Calls)에서 구현해야 할 파일 관련 시스템 콜은 다음과 같다. create 정의 bool create (const char *file, unsigned initial_size); 'create' 시스템 콜은 'file'이라는 이름으로 초기 크기가 'initial_size'인 새로운 파일을 생성한다. 즉, 파일 시스템에 새로운 파일을 만들고 초기 크기에 해당하는 공간을 할당한다. 이 과정에서 파일이 열리는 것(open)은 아니다. 파일을 열기(open) 위해서는 별도의 'open' 시스템 ..
x86-64 기반 Pint OS 프로젝트 2의 System Calls를 구현하기 위해 공부한 개념을 정리한다. fork 정의 pid_t fork (const char *thread_name); thread_name을 name으로 가지는, 현재 실행 중인 프로세스의 클론(자식) 프로세스를 만든다. fork 함수는 자식 프로세스의 PID(프로세스 식별자)를 반환해야 한다. 반환 값이 0인 경우는 자식 프로세스에서 실행 중임을 나타낸다. 자식 프로세스는 부모 프로세스의 자원(file descriptor, 가상 메모리 공간 등)을 복제해야 한다. 부모 프로세스는 자식 프로세스가 성공적으로 복제되었는지 알기 전까지 fork 호출에서 반환되지 않는다. 즉, 자식 프로세스가 자원을 복제하는 데 실패한 경우, 부모 프..
