※ 이 포스팅에서는 System call 중에서, File manipulation 부분만을 다룬다.

흐름이 엉망일 것임을 미리 언급한다..

.
.

user program은 kernel area에 직접 접근할 수 없다.
시스템콜을 통해 커널 모드로 진입하여 파일을 읽는다던지, 쓴다던지, 하고자 하는 일들을 수행할 수 있다.
kernel area로 진입하려면 user program은 system call이라는 인터페이스를 사용해야 한다.

이 때, kernel area로 진입하면 context switching이 일어나게 된다.
그러면 이 사이에 user program이 하고자 하는 일을 어떻게 기억하여 kernel mode에서 수행할 수 있을까?

요러캐 된다.
즉, intr_frame이라는 장치에 유저 프로세스의 레지스터를 저장하여 kernel mode로 넘긴다.
kernel은 적절하게 처리하고, 결과가 있다면 레지스터에 저장하여 유저 프로세스로 다시 넘긴다.
kernel mode에서 user mode로 넘어갈 때도 intr_frame을 사용하여 복구할 수 있다.

• %rip
  CS:APP 3장에서 봤던 내용 중에 다른 프로그램으로 jump했을 때, 그 프로그램이 종료된 이후에 기존 프로그램으로 돌아오기 위해서 jump 전에 다시 돌아올 주소를 스택에 push 했었다.
  user program이 시스템콜을 호출하여 커널 모드로 전환되기 전, 다시 돌아와서 실행될 위치를 %rip 레지스터에 담아둔다.
• %rsp
  그리고 스택 끝을 가리키는 %rsp도 intr_frame에 포함된다.
• R
  gp_registers R은 인자를 전달하거나 결과값을 저장하는 일반 레지스터이다. 아마 general pointer이려나..?
• ds, cs, ss
  data section, code section, stack section이라는 의미이다.
  .
  x86-64 시스템에서는 의미가 흐릿해졌지만, 레거시와의 호환을 위해 남아있다. 또한 유저 모드인지 커널 모드인지 권한을 확인하는 용도로 쓰인다고도 한다.
  그렇다면 x86-32 시스템에서는 어떻게 사용되었을까?
  세그멘테이션이 도입되던 시기, 이 레지스터들의 역할은 중요했다. 자세한 내용은 아래 블록을 참고하자.

  x86-32 시스템에서는 MMU라는 하드웨어의 도움 없이, 오직 소프트웨어로만 각 세그먼트를 논리적으로 분리하였다.

  그래서 각 세그먼트, data 영역을 예로 들면, data segment에 접근하기 위해서는 data segment의 base address와 그 segment에서의 offset이 필요했다.
  그리고 그 주소가 유효한 주소인지 검증해야한다. 각 segment 메모리 공간을 지켜주기 위해서 Base + Offset + Limit 으로 접근 경계를 제어했다.

  즉, 각 segment별로 별도의 base address가 있었다는 말이다.

  하지만 이 기법은 너무너무너무 느리다.
  특정 데이터에 접근하려고 하면 해당 segment의 base 주소, offset을 알아야 하고, limit을 확인해야 한다. 이를 또다시 물리 주소로 변환해주어야 했다.

  현재 64bit 체제에서는 하나의 가상메모리 안에서 논리적으로 각 segment를 분리하지만, segment 단위로 물리 메모리에 매핑하는 것이 아니라, page 단위로 물리 메모리에 매핑한다.
  이 기법이 가능한 이유는 하드웨어의 도움을 받기 때문이다. MMU는 CPU 바로 옆에서 kernel이 관리하는 page table을 참고하여 빠른 속도로 해당 page를 물리 주소로 변환할 수 있다.

여하튼 이렇게 user program은 system call을 통해 kernel mode에서 작업을 수행한 결과를 return 받을 수 있다.

이 자료가 Pintos에서 user program이 system call을 호출하여 return 받게되는 과정을 잘 이해할 수 있도록 도왔다.

user program은 system call을 호출한다. 이는 syscall.c 에 정의된 인터페이스인데, user mode에서만 사용하는 것으로, kernel mode에서 잘 처리할 수 있도록 CPU는 레지스터에 각 인자들을 세팅한다.

kernel mode로 전환되면, interupt vector table에서 어떤 처리를 해줄지 판단한다.
우리는 system call을 호출했기 때문에 0x30이라는 값으로 syscall_handler()로 매핑된다. 이때, user stack에는 system call을 호출하면서 같이 넘긴 인자들이 CPU에 의해 push 되어있다.

우리는 마지막으로 syscall_handler를 커널 입장에서 적절하게 구현해주면 된다.

헉..
오케이오케이..

가보자가보자..ㅠㅠ

---

User Memory Access

깃북에서는
%rdi, %rsi, %rdx, %r10, %r8, and %r9
이 순서로 인자들이 저장되어 kernel area로 넘어온다고 했다.
그러면 syscall_handler에서는 이 인자들을 적절히 취하고 원하는 작업을 처리해주면 된다.

그런데 이렇게 넘긴 주소를 역참조했을 때,
유효하지 않은 주소일 수 있지 않나.
그렇기 때문에 첫번째로 유효한 주소인지 아닌지 확인해주어야 한다.

아래에 해당한다면 유효하지 않은 포인터인 것이다.
1. pointer가 null이다.
2. pointer가 virtual memory에 매핑되지 않았다.
3. pointer가 kernel 메모리 주소이다.

void check_address(void* addr) {
	if (addr == NULL || !is_user_vaddr(addr) || pml4_get_page(thread_current()->pml4, addr) == NULL)
	{
		exit(-1);
	}
}

System call

kernel이 system call을 처리할 때는 user program에서 전달받은 인자들을 잘 조합해서 적절한 처리를 해주어야 한다.
user program이 넘긴 인자는 CPU에 의해 register에 잘 저장되어 넘어온다.

.
.

특히나 잘 기억해야 할 것은

이 부분이다.
%rax에는 system call number가 저장된다. 이 번호에 따라서 처리해주면 된다.
halt, exit, fork 등 각각의 system call에는 고유한 번호가 있다.

.
.

이 번호를 어떻게 아냐면,,

요기 syscall-nr.h에서 이렇게 쓰기로 약속했다.

.
.

그리고 더 중요한 사실은
아래의 레지스터 순서대로 arguments가 전달된다는 점이다.

%rdi, %rsi, %rdx, %r10, %r8, %r9

.
.

또 이 부분! 하나만 더

return value는 %rax에 저장해서 반환한다.

위의 디렉션에 따라 아래와 같이 초기 설정을 해줄 수 있겠다.
몇 가지 system call을 구현한 상태의 코드이니 참고

• syscall_handler() 초기 설정

void
syscall_handler(struct intr_frame* f UNUSED) {
	// TODO: Your implementation goes here.
	/* %rdi, %rsi, %rdx, %r10, %r8, and %r9 */
	int syscall_number = (int)f->R.rax;

	switch (syscall_number)
	{
		/* Projects 2 and later. */
	case SYS_HALT:
		halt();
		break;
	case SYS_EXIT:
		exit(f->R.rdi);
		break;
	case SYS_WRITE:
		f->R.rax = write(f->R.rdi, f->R.rsi, f->R.rdx);
		break;
	case SYS_CREATE:
		f->R.rax = create(f->R.rdi, f->R.rsi);
		break;
	case SYS_REMOVE:
		f->R.rax = remove(f->R.rdi);
		break;

	default:
		exit(-1);
		break;
	}
}

그 다음은 실제로 시스템콜을 하나씩 구현해야 한다.(웁스....)
깃북에 나온대로 해본다.

halt()

power_off() 를 호출하면 된다고 한다.

#include "threads/init.h"

void halt(void) {
	power_off();
}

exit()

깃북에는 힌트가 없지만 유튜브에는 있따..!
유튜브를 꼭꼭 보는 것이 좋다. 확실히 이해가 빨리 되고, 감이 잡힌다.
링크 참고

thread_exit() 을 사용하여 구현하면 되고,
"name of process: exit(status)" 를 출력해야 한다.

여기에서는 이 함수에서 status값을 변경하는 이유를 알아야 한다.
user program이 종료될 때 실행되는 시스템콜이다.
만약, 이 프로세스를 기다리고 있는 부모 프로세스가 있다면 부모 프로세스에게 종료를 알려야 한다.
부모 프로세스가 해당 프로세스의 상태를 추적할 수 있도록 해야한다.

따라서, thread 구조체에 exit_status를 추가해주고 상태를 업데이트해준다.

/* struct thread */
enum thread_status exit_status; 
    
/* syscall.c */
void exit(int status) {
	struct thread* curr = thread_current();
	curr->exit_status = status; // 부모 프로세스가 알 수 있도록

	// thread 이름 출력
	printf("%s: exit(%d)\n", curr->name, status);
	thread_exit();
}

create()

여기서 많이 헤맸다.
위에서는 바로바로 처리되는 간단한 시스템콜이었지만,
create 함수는 disk도 확인하고, sector도 확인한다. 새로운 파일을 생성할 공간을 확인한 후에 해당 파일명으로 생성한다.
따라서 시간이 좀 걸린다.

이는 유튜브에도, 깃북에도 가이드가 없지만 여기저기 file 관련된 파일들을 뒤져보면 비슷한 기능을 하는 함수가 정의되어있음을 쉽게 발견할 수 있다.

이 함수다.
이것만 가져와서 사용하면 된다.

bool create(const char* file, unsigned initial_size) {
	check_address(file);
	return filesys_create(file, initial_size);
}

아니 근데 자꾸 에러가 뜨는 거다🤬

이렇게 말이다.

아니, file명도 잘 들어가고(아 지금 생각났는데 thread_create 시, thread명 또한 잘 파싱해줘야 한다)
다 다 잘 수행되는데 왜 자꾸 잘 끝나지가 않냐고..

진짜 반나절은 넘게 붙잡고 있었는데
이번에도 수호천사 권호님이 도와주셨다.. 하..
늘 본인 일처럼 고민해주셔서 감사하다 🥲

여튼 문제는 임의로 작성해둔 process_wait()의 시간이 너무 짧아서, 미처 create 되기 전에 메인 스레드가 종료된다는 점이었다.

내가 왜 이걸 캐치하지 못했을까?
구조를 잘 이해하지 못하고 있었다고 판단했다.

더 알아보자.

---

크게 이런 흐름으로 테스트 케이스가 실행되고 있다.

하나씩 보자면,
우선 init.c가 실행되며 main thread가 생성된다.
이 main thread는 모든 테스트 케이스를 실행시켜주는 root 역할을 한다.

main thread는
위와 같이 process_create_initd()를 수행하며 자식 프로세스를 만들게 되고,
그 자식 프로세스를 process_wait()으로 종료되기를 기다려야 한다.

하지만 우리는 아직 process_wait()을 구현하지 않았기 때문에 자식 프로세스를 기다리지 않고, 그냥 for문을 탈출할 동안만 실행되게끔 임의로 설정하였다.

그 이후에는 이렇게 thread_exit()을 만나게 되어 main thread는 종료된다.

이 때, 자식 프로세스가 완전히 실행되기 전에 종료된다면 문제가 생긴다.

자식 프로세스는 main thread에 의해 생성되고, do_iret()을 통해 user program으로 전환된다.
이후에는 %rip에 저장된 주소로 이동하여 테스트 파일을 수행한다.

만약, main thread의 종료가 테스트 파일의 수행보다 더 앞서게 된다면 내가 겪은 문제를 마주하게 된다..

.
.
.

또 하나의 의문이 생겼다.
코드를 봤을 때, 유저 프로그램이 main.c/main() 함수부터 실행된다는 사실을 어렴풋이 눈치챘다.
make tests/~~ 를 했을 때, 출력문이 main() 프로그램과 동일하게 나오기 때문이다.
그런데 어떻게 main() 프로그램으로 실행되는 걸까???
create-normal도, args-single도, 유저 프로그램은 전부 main() 프로그램이 시작점이 된다.

make tests/~~ 를 하면 내부적으로는 아래의 명령을 실행한다.
pintos --fs-disk=10 -p tests/userprog/create-normal:create-normal -- -q -f run 'create-normal'

무심코 입력한 명령어에서 실은 전부 지정해주고 있었다.
이런 흐름으로 우리는 user program을 테스트할 수 있다.

open()

깃북에서는 이렇게 설명한다.

file이 들어갈 수 있는 file descriptor를 찾아 반환하거나, 없다면 -1을 반환한다.
0과 1은 이미 예약되어있으니, fd는 2부터 사용하면 된다.(0은 표준 입력, 1은 표준 출력)
참고로, 원래 2번은 표준 에러로 예약되어있긴 하지만 pintos에서는 입출력까지만 정의한다.

그 아래는 file descriptor에 관하여 더 설명하고 있다.

• file descriptor는 각 프로세스별로 독립적으로 구성된다.
• 그리고 child thread에게는 fd가 상속된다. 하나의 파일은 하나 이상의 프로세스에서 open될 수 있으며 서로 다른 file descriptor를 가진다.
• 그리고 각 프로세스는 독립적으로 파일을 close할 수 있어야 한다.

위의 내용을 file descriptor는 프로세스 내부에서 독립적으로 관리된다는 점을 시사할 수 있다.

.
.

유튜브 자료를 참고하여 더 이해해보자.

file descriptor는 Table에 의해 관리된다.
그리고 이 table은 64개의 entry를 가진다. 즉, 0~63까지 사용할 수 있다.

유튜브에서는 좀 더 많은 힌트를 준다!

file descriptor를 어떻게 저장할 수 있을 지에 대해 두 가지 방법을 제안한다.

thread 구조체에 file descriptor table을 두어 관리해야하며,
1. double pointer 혹은 2. pointer array 형태로 관리하기를 권장(?)한다.

next_fd의 정보는 생략 가능하기에, 나는 생략했다.
malloc을 구현할 때, 할당 가능한 메모리 공간을 찾을 때 사용하는 전략으로 first fit, next fit, best fit이 있었는데
이 next_fd를 저장하는 이유는 next fit과 비슷한 맥락으로 보다 빨리 빈 fd를 찾기 위함이 아닐까 생각했다.

여튼 나는 이렇게 구현했다.

• struct thread

	struct file** fd_table;

• syscall.c

int open(const char* file) {
	/* open 성공시, fd를 반환하고 실패시, -1을 반환한다. */
	check_address(file);

	struct file* f = filesys_open(file);
	if (f == NULL) {
		return -1;
	}

	struct file** fdt = thread_current()->fd_table;
	for (int fd = 2;fd < 64;fd++) {
		if (fdt[fd] == NULL || fdt[fd] == 0) {
			fdt[fd] = f;
			return fd;
		}
	}
	return -1; // fdt 전부 할당됨
}

여기까지는 쉽다.
그런데 꽤나 나를 애먹인 부분이 있었는데!

바로 구조체에 fd_table을 추가하고, 초기화를 해주는 과정에서였다.

당연히 모든 thread가 초기화되는 이 함수, init_thread()에서 초기화를 해주었다.
비어있는 fd는 0(NULL)이어야 하기에 calloc으로 초기화 해주었다.

그런데

자꾸만 이런 에러가 뜨는 거다ㅠ.. (지금 보니 친절하게 call stack을 뱉어줬었네 ㅎ assertion에 꽂혀서 눈을 감고있었나보다.)

t->status == THREAD_RUNNING
is_thread(t)
이 두 부분에서 번갈아가면서 에러가 생겼다.

결국, thread_current()를 호출하는 시점에 문제가 생겼던 것..

왜일까?

system call 코드에서 thread_current()를 호출한 게 문제인가 싶어, 계속 그 부분만 파봤는데 이게 문제가 아니었다.

init_thread()에서는 부팅과 동시에 최초의 main thread를 초기화 설정해주는 함수로도 쓰인다.

그런 init_thread() 내부에서 calloc을 호출하면 어떻게 될까?
calloc을 들어가보면..

calloc -> malloc -> palloc_get_multiple -> lock_acquire -> thread_current
이렇게 초기화 되기도 전에 thread_current()를 호출한다.

여기서 문제가 생겼던 것이다!

그래서 thread_create() 혹은 process_init() 등으로 옮겨주면 된다.

나는 이렇게process.c 파일에 초기화해주었다.

static void
process_init(void) {
	struct thread* current = thread_current();
	/* file descriptor 초기화 */
	current->fd_table = calloc(64, sizeof(struct file*));
}

close()

fd를 닫는다.
fd를 닫는다는 것은 기존에 file 구조체의 주소를 가리키고 있던 연결을 끊어주면 된다.

void close(int fd) {
	/* fd를 0으로 바꿔준다. */
	if (fd >= 2 && fd < 64) {
		thread_current()->fd_table[fd] = 0;
	}
}

filesize()

file_length() 를 사용하면 된다.

int filesize(int fd) {
	return file_length(thread_current()->fd_table[fd]);
}

read()

read 시스템콜은 두 가지 case로 구분하여 처리해야한다.

1. fd가 0인 경우, 표준입력으로 예약되어있기 때문에 하드웨어 인터럽트에서 읽어와야 한다. → input_getc() 사용
2. 그외, fd를 참고하여 읽어온다. → file_read() 사용

이 함수는 에러처리가 중요하다.

int read(int fd, void* buffer, unsigned size) {
	check_address(buffer);

	// 표준 입력의 경우, 키보드의 입력을 받음
	if (fd == 0) {
		buffer = input_getc();
		return size;
	}
	else {
		// 옳은 fd인지 확인
		if (fd < 2 || fd >= 64) {
			return -1;
		}

		// 접근한 file이 비어있는지 확인
		struct file* read_file = thread_current()->fd_table[fd];
		if (read_file == NULL) {
			return -1;
		}

		return file_read(read_file, buffer, size);
	}
}

read를 구현하면 write는 그냥 완성이라고 봐도 된다.

write()

이 경우도 두 가지 case로 구분하여 구현한다.
1. fd가 1일 경우, 표준 출력으로 예약되어있어 console에 write 한다. → putbuf() 사용
2. 그 외, fd를 참조하여 해당 file에 write 한다. → file_write() 사용

int write(int fd, const void* buffer, unsigned size) {
	check_address(buffer);

	if (fd == 1) {
		putbuf(buffer, size);
		return size;
	}
	else {
		// 옳은 fd인지 확인
		if (fd < 2 || fd >= 64) {
			return -1;
		}

		// 접근한 file이 비어있는지 확인
		struct file* write_file = thread_current()->fd_table[fd];
		if (write_file == NULL) {
			return -1;
		}

		return file_write(write_file, buffer, size);
	}
}

seek()

읽거나 쓰기 위한 다음 byte로 바꿔준다.(사실 어디에 쓰이는지 모르겠다.. 이미 구현되어있어서 갖다 쓰면 된다..)

void seek(int fd, unsigned position) {
	file_seek(thread_current()->fd_table[fd], position);
}

tell()

읽거나 쓰기 위한 다음 byte 위치를 반환한다.(이것도 사실 어디에 쓰이는지 모르겠다.. 이미 구현되어있어서 갖다 쓰면 된다..)

unsigned tell(int fd) {
	return file_tell(thread_current()->fd_table[fd]);
}

read-boundary는 왜 통과가 안 될까??
개별 실행하면 되는데 make check하면 안 된다.
고민 해보자.