회고 어제 하루 종일 매달렸던 문제를 간신히 해결했다. 원인을 알 수 없어서 이전 깃 푸쉬 내역으로 롤백하고 거기서 부터 다시 구현하다가 process_wait ()에서 시간을 많이 주니까 통과되더라... 너무 허탈했다. fork와 wait 시스템 콜을 바로 하기는 어려울 것 같아서 exec 부터 먼저 구현해보기로 했다. 2시간 정도 걸린 것 같다. exec 시스템 콜이 fork를 써야 하는 줄 알았는데 그건 아니었다. exec는 실행하고 싶은 파일명을 인자로 담아 호출하면 현재 실행 중인 프로그램을 새 실행 파일이 대체하는 시스템 콜이다. 따라서 커널 영역에 파일 이름에 대한 공간만 할당해주고 process_exec (file_name)을 호출하면 끝이다! 프로그램을 실행시키는 process_exec ..
발생 syscall_handler ()와 halt (), exit (), write () 시스템콜 함수를 구현하고 테스트해보기 위해 돌려보았는데, 모든 테스트케이스가 터졌다. halt ()와 exit () 함수가 틀리기도 어려운 정도의 쉬운 함수라서 어디서 틀린건지 도저히 알 수 없었다. 이틀을 넘게 코드를 뒤져봐도 원인을 알 수 없어서 포기하고, 이전 깃헙 푸쉬내역으로 롤백한 후 다시 구현했는데 통과했다.. 너무 허탈하다. 뭐가 달랐던 걸까? pintos -v -k -T 60 -m 20 --fs-disk=10 -p tests/userprog/args-dbl-space:args-dbl-space -- -q -f run 'args-dbl-space two spaces!' test..
회고 오늘도 똑같은 하루. 시스템 콜에 대한 로직을 이해하면서 블로그 글을 작성해보았다. 확실히 글로 적으면서 공부하니까 생각을 정리할 수가 있었다. 유저 모드에서 사용하는 시스템 콜과 커널 모드에서 사용하는 시스템 콜의 차이에 대해 확실히 알 수 있었다. 이전까지는 둘의 차이를 모른 채 어물쩍 넘어갔었는데 과제를 수행하며 궁금해진 것을 깊게 파다보니 알 수 있었다. 유저 모드에서 유저 프로그램은 커널에게 해당 시스템 콜의 "요청"을 보낸다. 유저 모드에서 커널 모드로 전환되고, 커널 모드에서는 시스템 콜 핸들러에서 시스템 콜 요청을 받고 해당 시스템 콜을 실행하고 결과를 리턴해준다. 유저 모드와 커널 모드 간의 통신은 레지스터로 이루어진다. 저녁부터 이상하게 기운이 없었는데, 밤 10시부터 아예 기력이..
회고 개인 사정으로 4일 동안 TIL을 쓰지 못했다. 오늘부터 다시 열심히 작성해야지. 현재 Pint OS 프로젝트 2를 진행하는 중이다. 첫 3일 동안 argument passing을 수행하고, 오늘은 user memory access와 system call을 공부한다. 6월 2일 금요일부터 Pint OS 프로젝트 2를 시작하고, 과제 수행 기간이 1.5주(10일)나 주어져서 꽤나 여유롭다고 생각했다. 프로젝트 2의 개요는 Argument Passing, User Memory Access, System Call, Process Termination Messages, Denying Writes to Executables이다. 프로젝트 1에 비해 확실히 많다.. 우선 Argument Passing부터 차근..
Virtual Memory Layout Pint OS에서 가상 메모리는 2개의 영역으로 나뉜다. User Virtual Memory: 가상 주소 0부터 KERN_BASE(0x8004000000) 사이의 영역 Kernel Virtual Memory: 가상 주소 KERN_BASE(0x8004000000) 이상의 영역 User Virtual Memory 유저 가상 메모리는 프로세스마다 할당된다. 커널이 한 프로세스를 다른 프로세스로 전환할 때, 페이지 테이블을 통해 유저 가상 주소 공간도 전환된다(Context Switching).구조체 thread는 프로세스의 페이지 테이블을 가리키는 포인터를 가지고 있다(curr_thread->pml4). 유저 프로그램은 오직 할당된 유저 가상 메모리에만 접근할 수 있다...
