Remind 지난 시간에는 임시 페이지 테이블을 만들기 위해 필요한 페이지 수를 계산해서 링커 스크립터를 통해 예약해둔 것을 확인할 수 있었는데요. 이번 시간에는 그 공간을 사용해서 임시 페이지 테이블을 만드는 과정을 살펴볼 것이에요. 이제 코드를 살펴보도록 할까요? 해당 글의 타겟 아키텍처는 aarch64이고, kernel code는 5.1버전을 다룹니다. 유의하세요! __create_page_tables 이전 시간에 이어서 다시 __create_page_tables 함수를 보도록 할게요. 이전에 init_pg 영역의 캐시 라인을 invalidate 했었고 그 뒤에는 identity mapping 테이블을 만드는 과정이 나와요. 실제 코드는 아래와 정확히 일치하지는 않는데요, 중간 중간에 minor한 일을 해주기 때문이에요. 하지만 핵심적인 부분 변환 테이블을 만드는 과정은 아래와 같이 진행되어요. 위 코드에서 보이듯이, map_memory 매크

UART 드라이버를 구현하자!

분석 과정에서 사용하는 환경이 일반적으로 우리가 사용하는 데스크톱 환경과는 다르니까, 이를 가능하도록 크로스 플랫폼 환경이 가능하게 Cross Compile, QEMU 가상화, Cross debugging 의 도움을 받으면서 진행보려고 해요. 우선 필요한 패키지를 설치해 보아요. 저는 데스크톱 리눅스 개발환경은 우분투를 주로 사용해요. 우선 간단하게 부팅가능한 정말 자그만한 OS Kernel 을 만들어볼께요. 만들기 위해서 찬찬히 RV64I ISA 기준으로 사용할 때 필요한 어셈블리 명령어들만 우선 보도록 할께요. TODO: 부팅 가능한 간단한 소스코드 TODO: 페이징 관련한 내용을 어떻게 여기에 넣을까?! 페이지 테이블을 만들다 말아볼까? 아래 그림은 64비트 RISC-V 아키텍쳐, 4K 페이지 기준 1단계 정규 페이징을 하는 예시에요. ( PTE 한 단계만 존재함 ) "페이징?! 1단계를 한다고? 무슨 말이야." "아 중간에 하나 있네, 1단

기나긴 compaction 분석이 거의 끝났지만, compaction 외에 migrate와 rmap과 같은 큼직큼직한 부분도 동시에 다뤘기 때문에 다시 한 번 compaction을 복습하는 시간을 가지면 유용할 것 같아요. Compaction 기본 개념부터 발전사에 따라 추가된 부분들을 되짚어 보며 최신 compaction에 대해 이해하는 방향으로 기술하도록 할게요. 1) /proc, /sys를 통해 트리거되면 compaction이 진행됨 2) direct compaction 추가, high order 할당 실패 시, reclaim 이전에 compaction이 호출되며 요청된 order을 만들어내기 위해 노력함. 3) async: migrate 함수에 의존. sync 인자가 추가됨. 7db8889ab05b57200158432755af318fb68854a2 mm: have order > 0 compaction start off where it lef

이론을 공부하고 커널 코드를 분석하여 완전히 이해하면 너무나 좋겠지만, 완전히 이해하기 힘든 부분이 존재하는 것 같아요. 저는 커널 코드를 분석하는 입장과, 커널 코드를 개발하는 입장의 차이는 생각보다 꽤 크다고 봐요. 그렇기 때문에 직접 OS를 개발하거나 커널 코드를 작성하는 것은 코드 분석에 많이 도움이 된다고 생각해요. 그래서 이번 시리즈에서는 WhoamI OS를 만들면서 Training에서 공부했던 내용을 복습하고, 부족한 부분들을 발견하고, 놓친 부분들을 있는지 체크하려고 해요. Series Linux kernel head.S 찍어먹기(1) Linux kernel head.S 찍어먹기(2) Linux kernel head.S 찍어먹기(3) Linux kernel head.S, main.c 분석하기 (1) (GDB + QEMU + BUILDROOT) 해당 Practice 시리즈는 Training에서 배운 내용을 직접 실습하는 내용을 담고 있

역(거꾸로) 매핑이 무엇일까요? 우선 가상 주소로 부터 물리 주소로 변환하는 ( Page Directory -> ... -> PTE -> PFN) "(포워드) 매핑"을 반대로 하는 것이에요! 즉, 역 매핑은 물리 주소(PFN)로 부터 가상 주소(각 태스크 마다 각자 매핑한)로 변환(Translation)하는 것을 말해요. 잠깐, 매핑을 추가로 더 한다면, 메모리 상용 공간 절약의 측면에서도 오버헤드가 생기는 도입한 이유는 무엇일까요? 역 매핑은 모든 페이지 테이블 엔트리를 찾아 매핑을 제거할 때(이런 동작을 LWN 에서는 page out 작업이라고 합니다.) 빠르게 하기 위해서 사용해요. 메모리 관리 측면에서 신속하게 페이지를 해제하고, 해당 사용했던 페이지 프레임을 다른 용도 재활용하기 위해서에요. 필요한 물리 주소 영역을 빠른 응답으로 양도 할 수 있도록 절충한거죠! 자 그럼 이제 역 매핑이 어떠한 자료 구조들에 의해서 수행할 수 있게 되는지

head.S 를 분석하거나, main.c의 start_kernel함수를 분석하는 과정에서 특정 변수나 레지스터의 값을 확인하고 싶을 때가 있습니다. GDB를 사용하면 자신이 분석중인 커널소스를 기준으로 라인바이 라인으로 이동하며 변수나 레지스터의 값들을 확인할 수 있습니다. 단지 커널소스 분석을 위해서라면 GDB + QEMU + kernel만 있어도 됩니다. 하지만 나중을(?) 위해서 BUILDROOT rootfs를 사용하여 커맨드라인까지 떨어지는 과정을 진행하려고 합니다. 시스템 환경 이 문서 내용들은 Ubuntu 20.04에서 진행되었습니다. QEMU + BUILDROOT(+GDB) 환경 설치 필수 패키지 설치 터미널을 열어 아래 명령을 실행합니다. qemu-system-arm의 경우 내부 패키지에 qemu-system-aarch64 바이너리가 포함되어 있습니다. $ sudo apt install git libncurses-dev qemu-sy

앞선 시간에서는 리눅스 커널 VM layout이 어떻게 배치되었는지에 대해 알아보았어요. 그리고 실제 배치된 물리 메모리와 가상 메모리가 다른 점을 해결하기 위해 변환 테이블(Translation Table)을 만들 필요가 있다고 했는데요. 그러면 이번 시간에는 본격적으로 head.S를 차근차근 분석해보도록 할게요. 해당 글의 타겟 아키텍처는 aarch64이고, kernel code는 5.1 버전을 다룹니다. 유의하세요! Head.S 부트 로더에서 커널 이미지 헤더로 제어권을 넘겨준다고 했는데요. 다시 한번 커널 이미지 헤더를 살펴볼까요? 부트 로더에서 14번 라인의 인스트럭션으로 jump하는 것을 QEMU를 통해서 확인했었는데요, 해당 인스트럭션은 stext로 branch를 하는 인스트럭션이에요. 이전 글을 잘 따라오셨다면 한 가지 질문이 드실 수 있는데요. stext는 심볼이고, 가상 주소로 되어있을텐데 물리 주소를 사용하는 현재에도 사용이 가

이전 포스트에서 링커 스크립터를 이용하여 오브젝트 파일들을 내가 원하는 주소에 재배치하는 과정을 살펴봤어요. 그러면 이러한 재배치는 그냥 임의의 위치에 해도 되는 것일까요? 사실 가상 주소의 영역들은 특정 목적에 따라 배정되었어요. 이렇게 배정된 영역에 링커 스커립트는 오브젝트 파일들을 재배치할 뿐이지요. 이번 포스트에서는 커널의 가상 주소 영역은 어떻게 결정되는지 확인할 것이에요. 이제 본격적으로 시작해볼게요. 해당 글의 타겟 아키텍처는 aarch64이고, kernel code는 5.1 버전을 다룹니다. 유의하세요! Virtual memory layout 지난 시간에 vmlinux.lds.S 파일을 잠깐 살펴봤을 텐데요, 호기심이 가득하신 분이라면 제일 head.S의 커널 이미지 헤더가 정말 이미지의 제일 앞에 배치되었는지 확인했을 것 같네요. 그래도 한 번 같이 확인할까요? Line 3번에서 위치 카운터를 KIMAGE_VADDR + TEXT_O