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

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

 

들어가기 전에...

0.시작하면서...

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

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

 

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

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

 프레임워크_블록다이어그램.PNG

<Framework Block Diagram>

 

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

  • Boot Loader : BIOS에서 제어를 넘겨받았을 때, 실행되는 부트 코드(Boot Code). 커널 로더(Kernel Loader)와 커널(Kernel)을 메모리에 로딩하는 역할. 로딩 완료 후 커널 로더로 제어 이관
  • Kernel Loader : 16bit 모드에서 32bit 모드로 전환하는 역할. 커널을 1Mbyte 위치에 재배치 한 후 커널로 제어 이관
  • Kernel : 실제 커널이 존재하는 부분. 메모리/인터럽트/태스크의 초기 설정을 수행하여 태스트들이 정상적으로 동작할 수 있도록 환경 설정 수행. 태스크 동작을 위한 Standard Library 제공

 

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

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

Startup.PNG

<Framework 실행 화면>

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

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

 

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

 

 

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

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

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

메모리_레이아웃.PNG

<Framework Memory Layout>

 

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

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

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

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

 

3.2 커널 재배치(Kernel relocation)

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

  1. 부트 로더가 0x10000 영역에 커널 로더와 커널을 적재한다.
  2. 부트 로더가 커널 로더로 제어를 이관하고 커널 로더를 실행한다.
  3. 커널 로더가 32Bit 모드로 전환하고 0x10000에 로딩된 커널을 0x100000(1Mbyte) 영역으로 이동한다.
  4. 커널 로더가 커널로 제어를 이관한다.

 

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

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

 

4.마치면서...

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

 

5.첨부

 

 

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

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

+ Recent posts