Part9. 프레임워크 컴파일 및 링크 방법

원문 :  http://kkamagui.springnote.com/pages/347128

들어가기 전에...

0.시작하면서...

 프레임워크는 부트 로더와 커널 로더 그리고 커널의 세가지로 나누어진다고 앞서 이야기 했다. 이제 각각을 컴파일하고 링크하여 커널 이미지를 생성해보자.

1.컴파일(Compile) 및 링크(Link) 환경

1.1 프레임워크 1.0.3 버전 이전 사용자

 프레임워크 1.0.3 버전 이전의 사용자는 아래의 배치 파일을 프레임워크 루트 폴더에서 찾을 수 있다.

 배치 파일로 되어있는데 각 파일을 열어보면 단순한 몇개의 명령으로 되어있다. 만약 위 단계에서 에러가 발생하면 에러메시지가 화면에 출력되게 되고, 해당 열을 찾아서 에러를 수정하고 다시 컴파일 하는 방법으로 작업을 계속 수행하면 된다.

 아마 커널을 자주 수정하게 될 것이므로  MakeKernel.bat와 MakeImg.bat 배치 파일은 마르고 닳도록 입력하게 될 것이다.

1.2 프레임워크 1.0.3 버전 이상 사용자

 프레임워크 1.0.3 버전 이상 사용자는 이클립스 환경에서 편리하게 사용하기위해 makefile이 통합되어있다. 빌드하는 방법은 간단히 아래와 같이 입력하면 된다.

 나머지는 makefile이 알아서 처리해준다. 에러가 발생하지 않는다면 disk.img 파일까지 완전히 생성해 줄 것이다. 간혹 종속성의 문제로 인해 제대로 빌드되지 않는 상황이 발생하는데 아래와 같이 입력하여 프로젝트를 깨끗히 정리한다음 다시 빌드를 수행하도록 하자.

1.3 커널 이미지 생성

 커널 이미지 만들기를 수행하면 내부적으로 Boot Image Maker(BIM.exe)라는 파일을 사용하는데, 자작한 프로그램이다. 이 프로그램이 하는 역할은 부트 로더와 커널로더 그리고 커널 이미지를 섹터 크기(512Byte)로 정렬한 다음 하나의 디스크 이미지 파일로 생성하는 것이다.

 부가적인 역할은 부트 로더 영역의 일부를 할애하여 전체 이미지의 크기 및 커널 이미지의 시작 위치 등을 기록하는 것이다. 이 값은 부트 로더가 디스크로부터 메모리에 로딩해야하는 섹터의 크기이며, 커널 로더가 1Mbyte 위치에 재배치해야하는 크기이다.

 BIM 코드는 아직 정리가 안되었기 때문에 추후에 올리기로 하고, 지금은 파일 상에서 어떻게 구성되는지만 확인하고 넘어가자.

<Boot Image Maker가 생성하는 이미지의 구성>

 위에서 보는 것과 같이 단순히 섹터크기로 맞추어 연결해 주며, 부트 로더의 뒷부분에 전체 이미지의 크기, 커널 시작 섹터, 커널 크기를 넣어주는 역할만 한다.

2.실제 컴파일 및 링크 화면

2.1 프레임워크 1.0.3 버전 이전 사용자

 아래는 MakeBoot.bat가 정상적으로 실행되었을 때 화면이다.

<MakeBoot.bat 실행>

 이 화면 외에 다른 메시지가 보인다면 그것은 에러 메시지이므로 에러를 처리하도록 하자.

 아래는 MakeKernel.bat가 정상적으로 실행되었을 때 화면이다.

<MakeKernel.bat 실행>

 이 화면 외에 다른 메시지가 보인다면 그것은 에러 메시지이므로 에러를 처리하도록 하자.

 마지막으로  MakeImg.bat가 정상적으로 실행되었을 때 화면이다.

<MakeImg.bat 실행>

 이 화면 외에 다른 메시지가 보인다면 그것은 에러 메시지이므로 에러를 처리하도록 하자.

2.2 프레임워크 1.0.3 버전 이상 사용자

 아래는 make가 정상적으로 실행되었을 때 화면이다. 프레임워크 1.0.3 이상 버전에 대한 빌드 및 환경 설정은 20 작업환경 설치 문서를 참고하자.

<프레임워크 빌드 진행 화면(좌측) 및 빌드 완료 화면(우측)>

3.커널에 파일 추가 방법

3.1 프레임워크 1.0.3 버전 이전 사용자

 커널에 기능을 추가하다보면 파일을 추가로 더 포함해야하는 경우가 생긴다. 그럴 경우 00Kernel 폴더의 Custom 폴더에 파일을 추가한 뒤에 makefile을 에디터로 열어서 수정하면 된다.

 그럼 어디를 수정해야 할까? 만약 스케줄링 기능을 넣어서 Scheduler.c 파일을 추가해야 한다고 가정하면 아래 부분을 고치면 된다.

1. # 응용 프로그램 파일
   FW.o : $(CUSTOMDIR)Framework.c
   1. $(GCC) -o FW.o $(CUSTOMDIR)FrameWork.c
2. KShell.o : $(CUSTOMDIR)KShell.c
   1. $(GCC) -o KShell.o $(CUSTOMDIR)KShell.c
3. Sch.o : $(CUSTOMDIR)Scheduler.c 
   1. $(GCC) -o Sch.o $(CUSTOMDIR)Scheduler.c 
4. #Object 파일 이름 다 적기
   #아래의 순서대로 링크된다.
   OBJ = A.o K.o Is.o D.o Int.o Key.o Stdlib.o Task.o FW.o KShell.o Sch.o

  위 처럼 파란색 부분을 추가해서 다시 makekernel.bat를 실행하면 정상적으로 커널에 포함할 수 있다.

3.2 프레임워크 1.0.3 버전 이상 사용자

 프레임워크 1.0.3 버전부터는 00Kernel 폴더의 Custom 폴더 및 FW 폴더 밑의 *.c 파일을 모두 찾아서 자동으로 빌드하도록 구성되어있다. 따라서 Custom 폴더 및 FW 폴더 밑에 .c 파일을 생성하고 make를 실행하면 된다.

4.마치면서...

 프레임워크 각 버전별로 빌드하고 이미지를 생성하는 방법에 대해서 알아보았다. 다음에는 프레임워크의 부트 로더 코드에 대해서 알아보자.

5.첨부

• part9.ppt

이 글은 스프링노트에서 작성되었습니다.

이 글은 스프링노트에서 작성되었습니다.

Part8. 까마귀(KKAMAGUI) 프레임워크(Framework) 설치

원본 :  http://kkamagui.springnote.com/pages/345299

들어가기 전에...

0.시작하면서...

 프레임워크 릴리즈에 대한 내용은  21 커널 프레임워크 소스 릴리즈 내용을 참고하자. 다음부터는 프레임워크를 사용해서 커널을 만들고 실행하는 것을 주제로 진행할까 한다.

이클립스를 이용하면 편리하게 빌드하고 테스트할 수 있데, 이클립스 설치 및 설정에 대한 자세한 내용은 06 이클립스(Eclipse) CDT 설치, 07 이클립스(Eclipse) 단축키 및 환경설정에 대한 문서를 참고하자.

프레임워크 빌드 환경에 대한 설정은 20 작업환경 설치 문서를 참고하자.

이 글은 스프링노트에서 작성되었습니다.

이 글은 스프링노트에서 작성되었습니다.

Part7. 까마귀(KKAMAGUI) 프레임워크(Framework) 소개

원문 :  http://kkamagui.springnote.com/pages/343186

들어가기 전에...

0.시작하면서...

 길고 긴 시간을 거쳐서 드디어 프레임워크(Framework)를 설명할 시간이 왔다. 프레임워크에 대한 이해를 돕기 위해 앞서 여러 파트에서 이것 저것 설명했는데, 설명이 부족했던 부분은 프레임워크 설명을 진행하면서 보충하겠다.

 그럼 지금부터 프레임워크에 대해서 하나하나 알아보자.

1.프레임워크(Framework) 블록 다이어그램

 아래는 프레임워크를 구성하는 블록 다이어그램이다.

<Framework Block Diagram>

 프레임워크는 위와 같이 크게 3개의 프로그램으로 구성되어있고, 각 프로그램의 역할은 아래와 같다.

2.프레임워크(Framework) 실행

 프레임워크를 실행하면 어떻게 되며, 어떤 상태에서 커널 코드를 작성하게 되는 걸까? 아래는 프레임워크 기본 소스를 그대로 컴파일 했을 때 화면이다(Virtualbox를 이용해서 실행시킨 장면).

<Framework 실행 화면>

 멋지지 않는가? 골치 아픈 문제를 다 뒤로하고 컴파일만 하면 간단한 쉘까지 포함한 아주~!! 간단한 커널이 나오게 된다. 만약 여기까지 아무것도 모르는 상태에서 어셈블리어 공부하고 Intel Architecture 공부하는 순서를 밟아서 진행한다면 사람에 따라 다르겠지만 무진장 @0@)/~ 걸린다.

 초반에 작성하는 16bit에서 32bit 전환 코드를 작성하기 위해서 Intel CPU Architecture를 정확히 이해하는데 걸리는 시간만 계산한다 해도 무시 못한다. 항상 겪는 문제지만 이론과 실제는 다르기 때문에 코드를 구현할 수 있는 수준에 오르기까지 또 시간이 걸리고, 구현했다 하더라도 열악한 디버깅 환경으로 인해 각종 fault에 부딪혀 좌절하게 된다(실제로 정석대로 밟아가는 많은 사람들이 이 부분에서 어려움을 겪는다).

 프레임워크를 사용하게되면 그러한 초반 로드(Load)를 거의 무시할 수 있기 때문에 실질적인 커널 개발에 시간을 더 많이 투자할 수 있다.

3.메모리 레이아웃(Memory Layout) 및 커널 재배치(Kernel Relocation)

3.1 메모리 레이아웃(Memory Layout)

 자 그럼 이제 프레임워크가 대충 무슨 기능을 해주는가 알아봤으니, 프레임워크의 메모리 레이아웃(Memory Layout)을 한번 보자. (빈영역이라 표현한 부분은 실제로 아무것도 없는 영역이란 의미가 아니라 어떤 용도로 사용되는지 정확히 알 수 없는 영역이다, BIOS마다 빈 영역의 용도는 다를 수 있다).

<Framework Memory Layout>

 그림으로 보면 복잡해 보이지만 차근차근 살펴보자. 커널은 1Mbyte 위치부터 시작하고 커널 스택은 4Mbyte가 Bottom이 되서 1Mbyte 영역 방향으로 자란다. 다시 말해 커널 영역은 총 1~4Mbyte 영역이고 1Mbyte 영역부터 커널 코드가 존재하고 스택 영역의 시작은 커널 코드 영역 끝 부분 ~ 4Mbyte 까지라는 것이다.

 커널 코드의 크기가 커지면 사용가능한 스택의 양이 줄어든다는 이야기인가? 이론상으로는 커널이 커지면 스택의 공간이 줄어든다. 이 말은 스택에 공간을 많이 할당할 수록 커널의 코드를 덮어쓸 확률이 늘어난다는 말과 같다.

 하지만 걱정은 잠시 미루어 두자. 실제로 커널 코드를 작성해 보면 커널이 큰 기능을 하지 않는 한 1Mbyte가 잘 넘지 않기 때문에 크게 문제가 없다.

 만약 큰 크기의 어플리케이션을 작업해야 한다면 덮어쓸 가능성이 있지 않는가? 물론 가능성이 높지만 그러한 경우는 커널을 작성할 때 커널 코드 안에 큰 어플리케이션을 밀어넣는 것이 아니라, 어플리케이션을 동적으로 로딩해서 메모리에 배치하고 실행하는 방식으로 해결해야 한다. 큰 어플리케이션 코드가 커널에 있다는 것 자체도 낭비이고 커널은 실제로 꼭 필요한 코드만 포함하는 것이 옳다.

3.2 커널 재배치(Kernel relocation)

 메모리 맵을 자세히 살펴보면 커널이 1Mbyte 영역에도 존재하지만 0x10000 영역에도 존재한다. 이것은 부트 로더에서 로딩한 것으로 부트 로더는 16bit 코드이기 때문에 1Mbyte 이상 영역으로 접근하기가 어렵다. 따라서 커널을 일단 1Mbyte 영역 아래에 로딩한 다음 다시 위치를 옮겨야 한다. 아래는 이 과정을 순서대로 나열한 것이다.

 자 그럼, 4Mbyte 이후의 영역은 어떻게 할까? 그것은 쓰기 나름이다. 동적 할당을 위해 영역을 할당할 수 있고, 필요하면 커널 스택 설정을 바꿔서 스택으로 사용할 수도 있다.

 프레임워크에서는 4Mbyte ~ 8Mbyte 영역을 동적 할당 영역으로 사용할 것이므로 참고로 알아두자.

4.마치면서...

 프레임워크에 대해서 간단히 알아보았다. 다음에는 프레임워크 컴파일 및 실행환경 설치에 대해 알아보자.

5.첨부

• Part7.ppt

이 글은 스프링노트에서 작성되었습니다.

이 글은 스프링노트에서 작성되었습니다.

 Part6. 부팅(Booting) 과정 소개

원문 :  http://kkamagui.springnote.com/pages/342881

들어가기 전에...

0.시작하면서...

 우리는 앞서 내용에서 OS를 제작할 때 알아야할 몇가지에 대해서 가볍게(??) 알아봤다. 너무 가벼운 관계로 쪼금 찔리긴 하지만, 일단 그 정도에서 접고 슬슬 프레임워크에 대해서 설명을 하겠다.

1.부팅(Booting)이란?

 프레임워크의 동작 과정을 알려면 첫째로 부팅과정에 대해서 알아야 한다. 그럼 도대체 부팅이란 것이 무엇일까?

 우리가 매일 쓰는 네이버의 백과사전을 검색해 보았다.

Booting(부팅)은 컴퓨터의 시동을 뜻하며, 보조기억장치(bootable device:주로 플로피디스크 또는 하드디스크)를 사용하여 컴퓨터가 동작할 수 있도록 시스템에 운영 체제를 불러 들여 작동을 준비하는 작업이다. 즉, 컴퓨터 시스템을 시동하거나 초기 설정하는 것을 뜻한다.
일반적으로 컴퓨터의 전원을 켜면 먼저 부팅 프로그램을 불러 들이고, 부팅 프로그램은 운영체제(Operating System)를 기억장치로 불러 들여 컴퓨터가 작동을 할 수 있도록 준비한다.
처음 사용자가 컴퓨터의 전원을 넣는 것으로 시작하는 부팅을 콜드(cold)부팅이라 하고 원래 전원이 들어와 있는 상태에서 하는 부팅을 웜(warm)부팅이라 한다.

 그렇다. 바로 컴퓨터를 시동하는 작업을 이야기 하는 것이다. 그럼 우리가 PC를 시동하면 어떤일이 발생하는가?

 다들 알겠지만 시커먼 바탕화면에 마치 무슨 콘솔(Console)처럼 흰 글자가 화면에 찍히고 램용량 표시/CPU/HDD 정보 표시 등등이 나타난다. 이 과정을 POST(Power On Self Test)라고 하는데 메인 보드의 BIOS(Basic Input Output System)에서 자체적인 하드웨어 점검을 해주는 것이다. 여기서 이상이 생기면 비프(Beep) 음이 울리게 되고 더이상 진행되지 않는다. 이 테스트에서 별 이상이 없으면 하드디스크를 읽어서 메모리에 적재한 뒤에 OS가 실행되게  된다.

2.부팅(Booting) 과정

 그럼 대충 어떤 것인지 알아봤으니 조금더 상세하게 알아보자. 아래는 실제로 부팅이 될때 그 과정을 나타낸 것이다.

<Boot Process>

 위에서 보면 알겠지만, BIOS는 Boot Sector를 로딩해주는 것으로 일을 마친다. 다시말하면 Boot Sector부터 커널을 로딩해서 OS를 동작시키는 것은 우리의 몫이다.

 그렇다면 부트 코드(Boot Code)부터 전부 작성해야 한다는 이야기인가? 그렇다. 전부 다 작성해야 한다.

 부트코드를 작성하는 데, 설마 C로 하겠지라고 생각하는 사람은 없을 것이라 생각한다(예전에 아무것도 모를 때, 친구가 베이직으로 OS를 작성할 것이라고 이야기 했었는데... 갑자기 그 생각이 난다).

 생짜로 어셈블리어로 짠다 @0@)/~~~ ㅜ_ㅜ

3.부트 코드(Boot Code) 및 커널 로더(Kernel Loader)

 부트코드를 어셈블리어로 작성해야한다는 사실이 초보 레벨의 프로그래머에게 굉장한 부담이 되긴 하지만, 좋은 소식이 있다. 사실 부트 코드가 굉장히 간단하고, 기능이 다 비슷하기 때문에 어느정도 정형화된 코드가 있다.

 또한 한번 만들고 나면 거의 손볼일도 없기 때문에 여기저기 참고해서 만들어도 큰 문제가 없다(배우는 입장에서는 한번 짜보는 것이 당연히!!! 좋다). 부트 코드는 BIOS에 의해서 0x7C00에 로딩되게 되는데, 그렇다면 이 부트코드는 어디에 있는 것일까?

 전통적인 이유로 인해 16bit XT시절부터 지금까지 하드디스크 또는 플로피 디스크의 첫번째 섹터에 부트 코드가 있다. 이런 물리적인 장치의 한 섹터의 크기가 512Byte이므로 부트 코드의 크기도 512Byte로 한정되어있다. 512Byte라니... 이 크기로 무엇을 하란 말인가?

 실제로 부트코드에서 뭐 좀 제대로 일 할려고 하면 512Byte의 크기를 넘는다. 따라서 부트 코드에서는 간단히 이미지를 디스크에서 메모리로 로딩하는 역할만 한다. 그후 커널을 재배치하고 기초적인 환경 설정을 해주는 프로그램을 실행하는데 그것이 커널 로더(Kernel Loader)이다. 커널 로더와 커널은 분리되어있는 경우도 있고 같이 있는 경우도 있는데, 프레임워크에서는 분리하여 구현하였다.

 프레임워크와 같이 분리하여 구현하는 경우 커널 로더가 커널 로딩에 책임을 지게되고 커널 실행을 위한 환경 설정도 책임지게 되므로 부트 코드는 아주 간단해지는 장점이 있다.

4.커널(Kernel) 실행

 마지막으로 커널 로딩이 끝나고 나면 커널로더에서 커널의 시작 주소로 Jump하여 커널을 실행하고 이제 본격적인 OS의 동작이 시작된다.

5.마치면서...

 오늘은 간단히 부팅과정에 대해서 알아봤는데, 다음에는 프레임워크에 대해서 좀더 자세히 알아보자.

6.첨부

• Part6.ppt

이 글은 스프링노트에서 작성되었습니다.

이 글은 스프링노트에서 작성되었습니다.

Part5. Intel Architecture에 대한 소개

원문 :  http://kkamagui.springnote.com/pages/339549

들어가기 전에...

0.시작하면서...

 앞서 인터럽트와 어셈블리어에 대해서 설명을 했다. 이제 프레임워크의 기반 환경인  Intel CPU Architecture에 대해서 알아보자.

1.Intel Architecture 다이어그램

 아래 그림은 System Programming 관점에서 본 i386 Architecture에 대한 그림이다. (참고로 여기 나오는 모든 그림은 다 Intel Architecture Manual에서 찾을 수 있다).
 

<Intel System Architecture>

 굉장히 복잡하게 그려져있는데, 프레임워크를 이해하기위해 필요한 부분은 General Register, Segment Register, Descriptor 정도이다.

2.레지스터(Register)와 16/32bit 모드(Mode)

 i386 Architecture는 16bit와 32bit 두가지 모드를 가지고 있는데, 16bit모드 일때와 32bit 모드일때 Segment Register의 역할이 다르고 사용가능한 General Register의 크기가 다르다는 차이가 있다. 16bit 모드에 대해서는 궁금한 사람은 Intel Architecture 메뉴얼을 참조 하도록하고 여기서는 32bit 모드에 중점을 두겠다.

2.1 레지스터(Register) 종류

 32bit 모드를 보호 모드(Protected Mode)라고 하는데, 권한에 따른 메모리 보호와 접근 범위 설정이 가능하기 때문이다. 32bit 모드에서 레지스터는 아래와 같이 구성된다.

<32bit Mode Register>

 위의 각 레지스터 역할은 아래와 같다. 

• General Register : 연산이나 비교, 저장 용으로 사용되는 레지스터
• Segment Register : Descriptor를 지시하는 역할을 하는 레지스터
• EFLAGS Register : 비교연산이나 산술연산의 결과의 Overflow, Underflow 같은 연산에 대한 결과 값과 인터럽터 가능/불가와 같은 전체적인 상태값을 저장하는 레지스터
• EIP Register : 수행중인 명령의 위치를 가리키는 레지스터(Instruction Pointer)

 Segment Register는 디스크립터(Descriptor)를 지시하는 역할을 한다고 했는데, 디스크립터에 대해서는 다음에 상세하게 알아보도록 하자.

2.2 세그먼트 셀렉터(Segment Selector)

 32bit Mode에서 Segment Register의 역할은 아주 단순하다. 바로 디스크립터를 지시하고 현재 Level(Ring 0, Ring1, Ring2, Ring 3)을 표시하는 역할이다.

 아래는 Intel Architecture에서 Segment Register의 비트별 용도를 나타낸 것이다.

<Segment Selector>

 Bit 3~15까지가 실제 디스크립터의 인덱스를 의미한다. 그렇다면 아래의 3bit의 용도는 무엇일까? 3bit의 용도는 아래와 같다.

• TI bit : 디스크립터가 전역 디스크립터 테이블(Global Descriptor Table)에 있는지 지역 디스크립터 테이블(Local Descriptor Table)에 있는지를 의미
• RPL bit : 해당 디스크립터에 접근하기위한 권한 레벨. 만약 RPL이 디스크립터에 설정된 DPL보다 값이 크면(낮은 레벨이면) 디스크립터에 접근 불가

 디스크립터의 인덱스 설정과 동시에 권한을 설정해 주는 필드로 체워져 있음을 알 수 있다. 권한에 따른 보호는 CPL과 RPL 그리고 DPL이 서로 엮여져 있는데 이에 대한 자세한 내용은 참고. Intel i386 CPU의 보호(Protection) 방식을 참고하자.

2.3 디스크립터(Descriptor)

 디스크립터(Descriptor)가 무엇인고 하니, 메모리 범위를 지정하고 해당 메모리의 속성을 지정하는 기술자(Descriptor)이다. 언듯 이해가 잘 안갈텐데, 이것을 이해하려면 OS의 메모리 관리 기법중에 세그먼테이션(Segmentation)에 대한 내용을 알고 있어야 한다. 세부적인 내용은 OS책을 보도록 하고 간단히 개요만 설명하겠다.

<Segment Register와 Segment의 관계>

 위의 그림이 Segment Register와 디스크립터의 관계를 표시한 것이다. 각 Segment Register는 한개의 디스크립터를 지시할 수 있고,  디스크립터는 코드영역인지, 데이터 영역인지, 스택영역인지에 대한 속성과 범위(시작과 끝)를 가지는 세그먼트(Segment)의 내용을 담고 있다. 즉 OS의 각 영역은 여러개의 조각(Segment)로 구분될 수 있으며, 각각의 세그먼트에 대한 구체적인 내용(속성, 시작, 끝 등등)을 가지고 있는 것이 디스크립터이다.

 하나의 디스크립터는 여러개의 Segment Register에 의해 선택될 수 있고, 극단적인 상황에서 모든 Segment Register가 하나의 디스크립터를 지시할 수 있다.(단 해당 디스크립터의 속성은 그에 합당하는 속성(코드/데이터 속성 등등)을 모두 가지고 있어야 한다.)

<Descriptor 구조체>

 디스크립터는 위에서 보는 것과 같이 시작 및 크기, 속성, 특권 레벨(DPL)로 구성되어있다. 디스크립터에 대한 자세한 내용은 Intel Architecture Manual 및 참고. Intel i386 CPU의 보호(Protection) 방식 문서를 참고하도록 하자.

 그럼 Segment와 General Register와 Address 간의 관계는 어떻게 되는걸까? 암묵적으로 Segment Register가 사용되는 부분은 아래와 같다.

 그렇다면 절대 주소(Absolute Address)의 계산은 어떻게 되는걸까?

 위와 같이 된다. 우리가 접근하는 위치는 디스크립터의 Base Address를 시작으로 하는 위치가 되기 때문에 이를 잘 생각해야 한다. 커널을 빌드하고 이를 실행했을 때 영향을 미치기 때문이다. 프레임워크에서는 단순하게 하기위해 Segment를 크게 2개(코드/데이터)로 구분하고 Base Address를 0, 크기를 4GByte로 설정했기 때문에 커널 코드에서 사용하는 위치는 절대 주소라고 보면 된다.

2.4 프로세스 모드(Processor Mode)

 자 그럼 여기서 잠깐만 Intel Architecture가 가지는 여러 모드(Mode)에 대해서 집고 넘어가자. 지금 16bit와 32bit 모드만 설명했는데, 2개의 모드가 전부일까?

 그렇지 않다. Intel Architecture Volume3을 참고하면 알겠지만 여러가지 모드가 존재한다.

<Intel CPU Mode 전환>

 위의 모드에 대해서 전부 설명하려면 책 한권으로도 부족하므로 궁금한 사람은 Intel Architecture Manual을 참고하도록 하고 간단히 설명만 하겠다.

 우리가 주로 사용하는 모드는 Protected Mode 이고 처음 시스템이 부팅되었을 때 모드는 Real-Address Mode라는 것만 알아두자.

3.스택(Stack)

 마지막으로 프로그램 제작이든 커널 제작이든 꼭 필요한 스택에 대해서 알아보자.

<Intel CPU의 Stack 구조>

 위의 그림에서도 나와있지만 i386의 스택은 높은 주소(0xFFFFFFFF 쪽)를 Base로 하고 낮은주소(0x0000 쪽)로 자라게 되어있다. 그렇기 때문에 앞서 본 호출 규약(Calling Convention)에서도 Parameter 접근시 ebp + 0x08과 같은 숫자를 더하는 방식으로 접근한 것이다.
 커널 프로그래밍을 하면 스택이 어느 방향으로 자라고 Top이 항상 어디에 위치하는지 확실하게 알고 있어야 한다. C와 어셈블리어 간의 함수 호출이라던지, 하드웨어적인 도움을 받지 않고 소프트웨어적으로 하는 태스트 스위칭이라던지 하는 부분은 모두 스택을 사용하기 때문에 스택을 제대로 이해하지 못하면 앞으로 나갈 수 없다.

 스택을 제대로 이해하고 있으면 불가능하게 보이는 일도 가능하게 만들 수 있다(32bit 모드에서 16bit BIOS 함수를 호출하는 것과 같은 일들...). 스택의 개념을 머리속에 항상 새겨놓도록 하자.

4.마치면서...

 Intel Architecture에 대해서 간단하게 알아보았다. 다음부터는 프레임워크에 대한 설명을 할 것이므로 지금까지 한 내용을 참고하면서 보면 많은 도움이 될 것이다.

이 글은 스프링노트에서 작성되었습니다.

이 글은 스프링노트에서 작성되었습니다.

Part4. 어셈블리어(Assembly Language)와 C 그리고 호출 규약(Calling Convension)

원문 :  http://kkamagui.springnote.com/pages/339546

들어가기 전에...

0.시작하면서...

OS를 개발하면서 초반에 어셈블리어로 작성한 코드를 보면, 사용한 어셈블리어 명령이 몇 종류 없는 것을 알 수 있다. 그것도 아주 기초적인 수준의 어셈블리어만 사용했는데, 역으로 말하면 몇가지 종류의 어셈블리어만 알고 있으면 부트로더(Boot Loader), 커널로더(Kernel Loader), 그리고 기타 초기화 함수를 작성할 수 있다.

1.어셈블리어(Assembly Language) 기초 명령

 아래는 기초 명령의 리스트이다(Intel Style의 명령이라 가정한다).

• mov A, B : B에서 A로 값을 이동
• cmp A, B : 두 값을 비교하여 결과를 Flags 레지스터에 업데이트
• rep instruction : insturction을 CX 레지스터의 값 만큼 반복 수행
• call X : Stack에 Return Address를 삽입하고 jump 수행
• jmp X : 무조건 해당 주소로 jump
• je, ja X : 조건 분기 명령. Flags 레지스터의 플레그 값에 따라서 jmp 수행(보통 cmp와 같은 명령어와 함께 사용)
• push X: 스택에 값을 저장
• pusha, pushad : 스택에 모든 레지스터 값을 저장. EAX, ECX, EDX, EBX, ESP, EBP, ESI, EDI 저장
• pop X : 스택에서 값을 꺼냄
• popa, popad : 스택에서 모든 레지스터의 값을 꺼냄. 위의 pushad 명령과 같은 순서의 레지스터 사용
• add A, B : A에 B의 값을 더함
• sub A, B : A에서 B의 값을 뺌
• mul A : EAX의 값과 A의 값을 곱하여 A에 저장
• inc A : A의 값을 1 증가시킴
• int X : X번째의 Software Interrupt를 발생시킴
• ret, retn : Stack에 포함된 Return Address를 꺼내서 해당 주소로 복구(보통 Call 명령과 같이 사용)
• iret, iretd : 인터럽트 처리 시에 모든 처리를 완료하고 다시 태스크로 복구
• or A, B : A에 B값을 OR
• xor A, B : A에 B값을 XOR
• not A : A의 값을 반전(0->1, 1->0)
• lgdt : GDT를 설정(Intel Architecture 특수 명령)
• lidt : IDT를 설정(Intel Architecture 특수 명령)
• lldt : LDT를 설정(Intel Architecture 특수 명령)
• ltr : Task Register에 TSS를 설정(Intel Architecture 특수 명령)
• clts : Task Switching 플래그를 0으로 설정(Intel Architecture 특수 명령)
• cli : 인터럽트 불가 설정
• sti : 인터럽트 가능 설정
• fninit : FPU 초기화 명령(x87 Floating Point Unit 관련 명령)
• ... 기타 등등

 물론 전부를 나열하지는 않았지만 척 봐도 알 수 있는 기본적인 명령어들이다. 물론 성능을 고려한다면 더 많은 어셈블리어 명령어들이 리스트에 포함되겠지만, 성능적인 면을 고려하지 않는다면 위의 함수 정도면 OK다.

 위의 함수에 대한 기본적인 기능들은 Intel Architecture Manual Volume 2 Instruction Set 문서를 참고하면 된다. 위의 명령어를 사용하여 프로그램을 작성하고 싶은 사람은 New Wide Assembler(NASM)을 이용하면 테스트 가능한데, 10 참고자료를 참고하면 간단히 함수를 생성하고 빌드 할 수 있다.

 http://nasm.sourceforge.net/ 홈페이지에 가면 컴파일러를 다운받을 수 있고 예제 및 문서도 제공하므로 한번 해보는 것도 괜찮을 듯 하다.

2.호출 규약(Calling Convention)

2.1 stdcall, cdecl, fastcall

 실제로 어셈블리어를 아는 것도 중요하지만 이 함수를 C 언어에서 어떻게 호출하여 사용할 것인가 하는 문제도 중요하다. 흔히들 호출 규약(Calling Convention)이라고 표현하는 이것은 함수를 호출하는 규약인데, 몇가지 방식이 존재한다.

 위의 세가지 중에서 보편적인 방식 두가지는 stdcall 및 cdecl 방식이다. 이 두가지 방식의 가장 큰 차이점은 스택의 정리를 누가 하는 가이다.

 stdcall 방식 같은 경우 Callee(호출 된 함수)에서 스택 정리를 하므로 Caller(호출하는 함수)와 Callee 모두 파라메터의 개수를 알고 있어야 정상적인 처리가 가능하다.

 반면 cdecl 방식 같은 경우 Caller에서 스택 정리를 하므로 Callee는 파라메터의 개수를 정확하게 몰라도 된다. 바로 이 점이 C 언어의 가변인자(Variable Argument)를 가능하게 하는 것이다(printf와 같은 함수를 생각해보자).

 가변인자에 대해서는 나중에 알아보고 우리가 사용할 cdecl에 대해서 자세히 알아보자.

2.2 cdecl 분석

 아래는 간단한 C 프로그램을 작성한 것이다.

1. int DoSomething( int a, int b )
   {
       int c;
       c = a+b;
       return c;
   }
2. int main(int argc, char* argv[])
   {
       DoSomething( 1, 2 );
3. }

 간단하게 파라메터 2개를 받아서 그중 첫번째 파라메터를 리턴하는 함수이다. 이것을 cdecl로 해서 컴파일 한 결과 나온 어셈블리어 결과는 아래와 같다.

1. int DoSomething( int a, int b )
   {
       int c;
       c = a+b;
       return c;
      /* 여기가 어셈블리어로 변경된 코드
       push ebp
       mov ebp,esp
       push ecx
       mov eax,[ebp+08h]
       add eax,[ebp+0Ch]
       mov [ebp-04h],eax
       mov eax,[ebp-04h]
       mov esp,ebp
       pop ebp
       retn
      */
   }
2. int main(int argc, char* argv[])
   {
       DoSomething( 1, 2 );
      /* 여기가 어셈블리어로 변경된 코드
       push ebp
       mov ebp,esp
       push 00000002h
       push 00000001h
       call SUB_L00401000
       add esp,00000008h <== 스택을 정리하는 부분
       pop ebp
       retn
      */
   }

 위에서 보면 파라메터를 역순으로 Push 하는것을 알 수 있으며 main 함수에서 "add esp,08" 명령을 통해 스택 정리를 수행함을 볼 수 있다. 여기서 주의해서 봐야 할 부분은 DoSomething 함수에서 어떻게 파라메터에 접근하고 또한 어떻게 함수 내부적으로 사용하는 레지스터를 관리하고 복원하는가 이다.

 아래는 Caller(main)와 Callee(DoSomething)의 스택의 상태를 표시한 것이다.

<Caller와 Callee의 Stack>

 왜 ESP로 접근하지 않고 EBP를 통해 파라메터에 접근하는 것일까? 위의 그림을 보면 왜 ebp + Index로 접근을 하는 지 알 수 있다. 스택의 Top을 의미하는 ESP 레지스터의 경우 코드 중간 중간에 스택을 사용하면서 계속 변하는 값이다. 그 반면에 파라메터의 위치는 항상 고정적이므로 스택의 Top을 이용해서 파라메터에 접근하려면 문제가 발생한다. 따라서 EBP에 ESP의 값을 처음 설정해 두고 EBP를 이용해서 고정된 Offset으로 접근하는 것이다.

 이와 같이 하면 스택의 Top이 계속 바뀌더라도 EBP가 초기의 스택 Top의 위치를 가지고 있으므로 EBP + 8, EBP+ 12과 같은 값으로 접근 가능하다. 위에서 초기에 Callee의 Stack에서 Push ebp를 하고 난 뒤에 Stack의 Top은 esp1을 가르키고 있다. 이 값을 ebp에 넣게 되므로 ebp를 이용하면 Parameter에 고정된 Index( 8, 12, 16...)으로 접근을 할 수 있는 것이다.

2.3 stdcall

 stdcall의 경우에는 cdecl과 거의 차이가 없고 스택을 정리하는 부분만 차이가 있다.

1. int DoSomething( int a, int b )
   {
       int c;
       c = a+b;
       return c;
      /* 여기가 어셈블리어로 변경된 코드
       push ebp
       mov ebp,esp
       push ecx
       mov eax,[ebp+08h]
       add eax,[ebp+0Ch]
       mov [ebp-04h],eax
       mov eax,[ebp-04h]
       mov esp,ebp
       pop ebp
       retn 08h <== 스택을 정리하는 부분
      */
   }
2. int main(int argc, char* argv[])
   {
       DoSomething( 1, 2 );
      /* 여기가 어셈블리어로 변경된 코드
       push ebp
       mov ebp,esp
       push 00000002h
       push 00000001h
       call SUB_L00401000
       pop ebp
       retn
      */
   }

2.4 프롤로그(prologue) 및 에필로그(epilogue)

 Callee의 스택을 다시 Caller의 스택으로 복원해야 하는데 스택 top을 저장하고 복원하고 하는 작업을 프롤로그(prologue), 에필로그(epilogue)라고 한다. 위에서 본 스택을 복구하는 작업이다.

 만약 우리가 어셈블리어 함수를 만든다면? 그리고 그 함수를 C에서 호출한다면? 아니면 그 반대의 경우라면 어셈블리어 함수를 어떻게 만들어야 할까? 그렇다. 위에서 본 것과 같은 형태 즉 cdecl의 형태를 그대로 따라서 만들면 된다.

 DoSomething() 함수의 프롤로그 에필로그 형태는 아주 일반적인 형태이므로 알아두도록 하자.(꼭 저렇게 구성할 필요는 없지만 일반적이므로 알아두자.)

3.마치면서...

 자 오늘 우리는 어떻게 어셈블리어 함수를 만들어서 파라메터를 넘겨 받을 것이며, 어셈블리어 함수에서 C 함수를 어떻게 호출해야 하는지, 혹은 그 반대의 경우 어떻게해야 하는지에 대해서 알아보았다. 다음에는 좀 더 깊은 내용에 대해서 알아보자.

이 글은 스프링노트에서 작성되었습니다.

Part2. 커널 개발시 꼭 알아야할 몇가지

원문 : http://kkamagui.springnote.com/pages/339543

들어가기 전에...

0.시작하면서...

 커널 개발 시에 알아야할 것이 프레임워크를 사용하면 많이 줄어든다고 이야기 했었다. 그렇다면 프레임워크를 사용해서 개발하면 정말 콜백(Callback)만 구현하는 방식으로 커널 개발을 완료할 수 있을까?

 글쎄... 이건 한번 생각해볼 문제인 것 같다. 초보라면 콜백과 API를 사용하는 것 만으로 충분하다. 하지만 프레임워크의 API는 시스템 또는 CPU Architecture의 특수한 기능을 수행하는 명령어를 사용하기 쉽도록 Wrapping 해놓은 것이기 때문에 시스템에 대한 어느정도 지식이 있으면 API를 '더욱 잘' 사용할 수 있다. 프레임워크(Framework)의 기능을 수정하거나 새로운 기능을 추가하려면 역시 시스템에 대한 지식이 필요하다.

1.권장 지식

 그럼 '꼭' 알아야 하는 것은 과연 무엇일까??
 내가 생각하는 꼭 알아야하는 것은 아래와 같다.

 적어도 이 정도는 빠삭(??) 하게 알고 있는 편이 커널 제작에 도움이 된다. 위 항목은 시스템 프로그래밍에 기초가 되는 부분이기도 하니, 저 정도의 지식은 갖추고 있는 사람이 꽤 될 것이다.

 적어놓고 나니, 아까 몰라도 된다고 했던 어셈블러는 갑자기 1번으로 등극해있고... CPU Architecture도 몰라도 된다면서 Interrupt 처리에 대한 내용이 나와있는건 또... ㅜ_ㅜ

 뭐.. 어디까지나 중급자를 위한 코스~!!! 라는 점을 강조하면서 마무리해야 겠다. 초급자는 프레임워크를 돌려 실행하기도 빠듯할 터이니 그냥 읽고만 넘어가자.
 그럼 고급자는?? 고급자는 이 글을 보지 않아도 이미 커널을 만들 수 있는 실력을 갖추고 있을 터이니 더더욱 패스...(왜 이걸 보고있을까.. ㅡ_ㅡa...)

 여튼 각설하고 중급자로 올라가려면 저정도의 지직은 갖추도록 하자.

이 글은 스프링노트에서 작성되었습니다.

이 글은 스프링노트에서 작성되었습니다.