(5/27)
오늘 살펴본 파일들: gdt.c, exception.c
gdt.c
GDT(Global Descriptor Table)은, 사용 중인 세그먼트(program의 특정 영역을 구성하는 단위)를 나타내는 table 이라고 보면 된다고 한다. 참고로 x86-64가 세그먼트(program의 기본 단위)로 세분화되어 있다.
gdt.c 를 열어보니, GDT는 시스템 내의 모든 프로세스에 의해 사용될 수 있는 segments를 정의한다고 나와있다. 물론, 실제로 사용될지는 각 프로세스의 허가 하에 이루어진다. GDT 내에서 byte offset을 통해 확인할 수 있는 각 테이블의 entry는 어떤 하나의 세그먼트를 식별해준다. PintOS 구현 과정에선 code, data, TSS 이렇게 3가지 세그먼트만 주로 활용하게 되는듯 하다.
참고로 byte offset이란, 쉽게 풀어 쓰자면 각 엔트리를 식별해주기 위해 어떤 시작 주소값에서 더해주게 되는 바이트 단위를 의미하는듯 하다.
exception.c
user process는 특별한 작업이나 금지된 작업을 할 때, exception 이나 fault 로서 커널로 들어가 트랩(커널 서비스를 제공받으려고)하게 된다고 한다. 그리고 이 exception.c가 바로 exception 을 처리해주는 파일이다.
보아하니, 만약 테스트를 돌리는데 debug panic이 뜬다면 exception이 어디서 발생했는지를 알려주는 위의 코드를 다시 살펴보아야겠다. 커널의 code 세그먼트나 어떤 다른 code 세그먼트에 의해 해당 exception이 발생하는 경우 panic이 발생한다는데, shouldn't happen 이라고 한다. 하지만 정글, where amazing happens...? 아마 구현하다보면 한번쯤은 분명 만날듯하니 미리 인사한 셈 치자.
만약 user code 세그먼트에 의한, 즉 우리가 발생할 것을 염두에 두고 있는 exception이 발생한 경우엔 단순히 메세지를 찍어주고 thread_exit()을 통해 해당 프로세스를 Kill해주고 끝나게 되어있다.
한편 page fault 함수도 상당히 흥미로운데, not_present / write / user 라는 3가지 bool 타입 변수를 설정하고, 각각을 intr_frame 타입의 인자 f의 error_code 필드와 비교하는 과정을 거친다. 그래서 결과적으로 셋 중 어떤 변수가 true로 설정되면서 page fault의 발생 사유가 셋 중 어디에서 기인한 것인지를 확인해주는 함수라고 일단 이해하고 넘어가야겠다.
