============================================================== 제목 : C 언어로 커널을 작성하기 위한 방법 원저자 : Tim Robinson (Mobius OS) 작성자 : edward 작성일자 : 2003. 12. 05 분석및번역: edward_frswz 분석버젼 : ver 0.0.1 라이센스 : GPL 홈페이지 : http://OSx86.ORG 원문참조 : http://www.themoebius.org.uk/tutes/ckernel.html ============================================================== ======================================================= - 준비물 - 요구지식 - 테스트 환경 틀린 내용이나 이상한 내용은 바로 메일로 씹어주세요. 제가 검증 후 바로 고쳐서 업데이트 하겠습니다. email : osx86@osx86.org ======================================================= 0. C 언어로 커널 작성하기 원작자 : Timothy Robinson(Mobius OS) E-Mail : timothy.robinson@ic.ac.uk 1. 소개 지금까지 여러분들이 가진 운영체제 개발에 대한 경험은 대개가 어셈블리 언어로 부트로더를 작성한 정도일 것입니다. 만약 여러분들이 어셈블리언어로 부트로더를 작성했다면 적어도 몇주는 걸렸으리라 봅니다. 따라서 더 나은 방법을 생각하게 하곤하죠. 대부분의 부트로더를 작성한 여러분들이라면 이미 C 프로그래밍 언어를 알고 있으리라 생각이 되고, C 언어가 그에 대한 충분한 대안이 될 수 있겠죠. C 언어 조차 잘 모르는 분들이라 하더라도 이미 몇가지 다른 하이레벨 언어를 익혔으리라 생각되며 이는 C 언어를 익히는데 도움이 되리라 봅니다. C 언어로 여러분의 커널을 코딩하기 시작하기 위한 기반이므로 충분히 익혀두시면 좋겠습니다. 2. C 프로그래밍 언어 C 언어는 근본적으로 로우레벨에 가까운 하이레벨 언어로 디자인 되었습니다. (유닉스 커널은 C 언어로 작성되어 오고 잇습니다.) 그리고 C 언어를 사용할 때의 가장 큰 이점은 뛰어난 이식성과 머신에 대한 용이한 접근에 있습니다. 물론 C 언어로 작성된 프로그램이 이식성이 떨어질수도 있지만 C 언어에 대한 약간의 지식만 있다면 이식성 있는 코드를 작성하는 것이 충분히 가능합니다. 그렇다면 그런점에서 C 언어로 컴파일된 코드는 어셈블리로 작성하는 것과 다른 어떤 특별한 점이 있을까요 ? 사실상, 여러분의 어셈블리 언어는 머신에 대한 Opcode 들과 1:1로 변환해주는 역할을 하는 단지 로우레벨 컴파일러에 지나지 않지만 여타 다른 하이레벨 언어처럼 C 언어는 추상적이며 머신에 대해 로우레벨 언어처럼 많이 생각할 필요가 없이 코드를 만들 수 있습니다. 그리고 무엇보다도 C 언어는 여러분이 작성할 코드에 대해 그리 많은 제약을 가하는 편은 아니랍니다. 3. 툴들(Tools) C 언어로 작성된 소스 코드를 머신이 실행가능한 코드로 만들기 위해서는 두가지의 중요한 소프트웨어가 필요합니다 : ====================================== 그것이 바로 - 컴파일러(Compiler) 와 - 링커(Linker) 입니다. ====================================== 컴파일러(Compiler)는 C 소스 코드를 오브젝트 파일(Object file)로 튜닝을 하는 일에 관한 대부분의 일을 처리합니다. 오브젝트 파일은 머신 코드와 데이터를 갖지만 그 자체로는 완전한 프로그램의 형태가 되지는 못한답니다. 많은 C 컴파일러들은 소스 코드로 부터 실행가능한 화일(executable file)을 바로 생성하는 옵션을 가지고 있지만 아마도 그러한 옵션을 사용할 경우 컴파일러는 내부적으로 링커(linker)를 호출하게 될 것 입니다. 링커(Linker)는 필요한 모든 오브젝트 파일(Object File)들을 서로 묶어주는 역할을 하고, 오브젝트 파일들에 존재하는 참조들을 서로 맞추고 그것들을 이동시키기도 하는데 이러한 작업을 재배치(relocation)라고 합니다. 이러한 재배치 작업을 마치고 실행가능한 파일을 생성해냅니다. 대부분의 링커는 컴파일러로 부터 호환가능한 오브젝트 파일 생성되는한 어떤 컴파일러로 만들어진 오브젝트 파일과도 동작이 가능합니다. 이는 여러분들이 머신에 종속적인 부분을 어셈블리로 작성한 뒤 그 외 커널의 대부분은 C 언어로 작성할 수 있다는 이야기입니다. 저는 GNU gcc 컴파일러와 ld 링커를 포함하는 패키지를 추천합니다. 왜냐하면 아래와 같은 이유 때문입니다 : ================================================================= * 이 소프트웨어들은 Free 하며 Open-Source 입니다. * ld 는 많은 실행가능한 포맷을 지원합니다. * gcc는 버젼에 따라 많은 프로세서에서 이용가능합니다. ================================================================= GNU 패키지들은 다양한 운영체제에서 이용이 가능합니다. MS-DOS 로 포트(port)된 버젼은 "DJGPP", Windows 로 포트(port)된 것중에는 Cygwin 과 같은 것들이 있죠. (% edward : 아래 링크를 참조하세요. ======================================= DJGPP : http://www.delorie.com/djgpp/ CygWin : http://www.cygwin.com/ ======================================= ) 모든 리눅스 배포판은 GNU 툴을 포함하고 있습니다. 각각의 시스템으로 포팅된 GNU 툴들은 컴파일러와 링커를 재 컴파일 하지 않는다면 사용중인 플랫폼에 맞는 코드를 생성합니다. 그리고 런타임 라이브러리는 OS 개발자에 의해 사용되곤 하는데 CygWin 프로그램에서는 Win32 API 를 사용하기위해 cygwin1.dll 에 의존하게 됩니다. 하지만 기본적인 런타임 라이브러리(RTL)를 무시하고, 당신 자신의 것을 작성할 수도 있습니다. 만약 여러분들이 Windows 에서 코드를 작성한다면 저는 Cygwin(ELF 를 지원할 수 있게 patch/rebuild 된 버젼)을 추천합니다. 왜냐하면 Cygwin 의 Flat Binary 출력은 부분적인 오류를 갖고 있습니다만 Cygwin 이 DJGPP 보다 약간 더 빠르고 긴 파일명과 명령라인을 지원하기 때문입니다. 다양한 다른 툴들도 OS 개발에서 유용하게 사용할 수 있습니다. GNU 의 binutils 패키지(gcc와 ld 와 함께 사용하기 위한 보조 프로그램)는 objdump 라는 프로그램을 포함하는데, objdump 는 여러분들의 실행가능한 파일의 내부구조를 검사할 수 있도록 도와줍니다. 더 중요한건 여러분들이 로더를 작성할때 어셈블리 코드의 tricky bit를 시도하게 될 것입니다. 일반적인 링커를 사용할때의 한 가지 단점은 여러분 스스로가 개발한 실행가능한 포맷을 링커들이 지원하지 못한다는 점입니다. 하지만 대개는 여러분 자신의 실행가능한 포맷을 개발한 필요가 별로 없습니다. 왜냐하면 이미 많은 종류의 실행가능한 포맷이 있기 때문이죠. UNIX 계열의 ELF 와 Windows 계열의 PE 포맷은 OS 개발자들이 가장 많이 사용하는 포맷입니다. 왜냐하면 대부분의 현존하는 링커들이 그 두 포맷을 매우 잘 지원하기 때문이죠. ELF 포맷은 아마츄어 커널에서 자주 사용되는 데, 그 이유는 PE 포맷이 더 좋지만 ELF 포맷이 단순하다는 이유로 사용하는 것입니다. (사실 PE가 더 좀더 복잡합니다.) 그리고 둘다 문서화는 잘 되어 있습니다. COFF 포맷이 동적 링킹(dynamic linking)과 같은 기본적인 기능에 대한 지원이 부족하긴 하지만 몇몇 커널 프로젝트에서만 사용되고 있습니다. 단순한 커널에 대해서는 아무런 포맷도 정하지 않는 순수한 바이너리 포맷 (Flat Binary Format)을 선택하기도 합니다. 이때 링커는 출력파일로 raw code 와 raw data 를 만들게 되고, 그 결과는 64KB의 헤더가 더 붙어 있는 MS-DOS 의 .COM 포맷과 비슷하며 로더가 보호모드를 지원한다는 가정하에서 32-bit opcode 를 사용할 수도 있습니다. 모든 IA-32 기반의 메인스트림에 대한 컴파일러의 단점은 32-bit flat address 공간이라 가정하고 CS,DS,ES,SS 각각이 같은 베이스 어드레스를 갖게 된다는 것입니다. 이점이 왜 문제 인가하면 이런경우에 far 포인터(48bit seg16:offset32) 를 사용할 수 없으며 ... far 포인터를 사용할 수 없게 되면 segmented OS 코드를 작성하기가 매우 힘들게 되기 때문입니다. C로 작성된 Segmented OS 기반에서의 프로그램은 상당한 부분을 어셈블리 코드에 의존하게 되고, Flat OS 기반에서 작성된 프로그램 보다 덜 효율적입니다. 그리고 이 글을 작성하는 시점에 Watcom 은 32비트 보호모드하에서 far 포인터를 지원할 것으로 추측되는 OpenWatcom 컴파일러를 릴리즈 할 것 같습니다. (% edward : 현 시점에선 릴리즈되어 있는 것 같군요.) gcc 와 ld 가 기능상으로 어떠한 컴파일러나 링커의 기능도 지원할 수 있지만 이 둘을 사용하게 될때 유의해야 할 점이 두가지 있습니다. 첫째는 gcc 는 함수 코드 바로앞에 리터럴 스트링(literal string)을 삽입합니다. 그렇다고 이것이 문제가 되는것은 아니지만 직접적으로 "Hello, world"를 출력하고자하는 사람들에겐 문제가 됩니다. 다음의 예를 봅시다 : ============================================================ int main(void) { char *str = "Hello, world", *ch; unsigned short *vidmem = (unsigned short*) 0xb8000; unsigned i; for (ch = str, i = 0; *ch; ch++, i++) vidmem[i] = (unsigned char) *ch | 0x0700; for (;;) ; } ============================================================ 위의 코드는 비디오 메모리에 화면 왼쪽 상단에 흑백으로 "Hello, world" 라는 문자열을 출력하고자 하는 것입니다. 하지만 위의 코드가 컴파일 될때, gcc 는 "Hello, world" 라는 문자열을 main 함수 코드 부분 바로 앞에 삽입하게 됩니다. 만약 컴파일된 파일이 순수한 바이너리 포맷(Flat Binary Format)으로 링크되어 실행된다면 이 문자열로 부터 실행이 시작되고, 머신은 이 코드를 이해할 수 없으므로 머신은 더 이상 동작하지 않을 것입니다. 위의 문제에 대해서는 두가지 대안이 있습니다 : ============================================================ * 하나는 main() 함수를 호출하고, 멈추게 되는 하나의 작은 함수를 작성하는 것입니다. 이 방법은 프로그램내의 첫번째 함수가 어떠한 리터럴 스트링도 포함하지 않게 하는 것이죠. * 다른 하나의 방법은 gcc 옵션인 -fwritable-strings 를 사용해서 컴파일 하는 것입니다. 그렇게 하면, gcc 는 리터럴 스트링을 실행가능한 데이터 섹션(data section)에 넣게 되고, 코드 섹션(code section)과는 떨어지게 됩니다. ============================================================ 여기서는 첫번째 방법이 조금 더 선호됩니다. 저는 어셈블리 언어로 엔트리 포인트 함수를 작성하는 방법을 좋아하는데 이 엔트리 포인트를 잡아주는 함수는 main 함수를 호출하기 전에 stack과 bss 섹션을 0 으로 만듭니다. 여러분들은 평범한 유저모드 프로그램에서도 이런것을 발견할 수 있는데 실제 엔트리 포인트(entry point)는 main() 함수를 호출하기 전에 그 프로그램을 동작시키기 위해 환경 설정을 해주는 C 라이브러리의 조그마한 루틴입니다. 이 루틴은 보통은 crt0 함수라고 입니다. (% edward : 일전에도 말씀드렸듯이 일반적인 유저모드에서 동작하는 C 프로그램이 main() 로 부터 시작하는건 아니랍니다. 보통 프로그래머는 main 함수로부터 시작한다고 생각하지만 그 앞에 몇 가지가 있답니다. 유저 프로그램의 로직과는 별로 관계가 없는 내용이죠. 그래서 main 함수로부터 시작한다고 막연히 알게 되는 것 같습니다.) 또 다른 문제점은 오브젝트 파일 포맷과 관련된 것입니다. 32-bit COFF 포맷에는 두가지 변형이 있습니다. 하나는 마이크로 소프트의 Win32 툴을 사용했을 때 생성되는 COFF 포맷과 나머지 하나는 마이크로 소프트의 Win32 툴을 사용하지 않고 여타 다른 툴을 사용했을 때 생성되는 COFF 포맷입니다. 이렇게 생성된 COFF 포맷 사이에는 미묘한 차이가 있는데, 다행스럽게도 링커들은 하나의 포맷을 다른 포맷으로 링크할 수도 있습니다. 하지만 이 둘의 차이는 근본적으로 재배치(relocation)와 관련되어 있습니다. : 만약에 여러분들이 NASM 으로 코드를 작성하고, 그렇게 작성된 코드를 Visual C++ 로 컴파일된 작은 모듈과 함께 마이크로 소프트의 링커를 사용해 링크하게 된다면 최종적으로 만들어진 결과물의 주소정보들은 엉망이 되어버릴 것입니다. 그래서 실제로 작업할때는 위와 같이 툴들을 섞어 쓰지는 않지만 다행스럽게도 마이크로 소프트의 PE(portable executable) 포맷을 지원하는 대부분의 툴들은 Win32 포맷의 파일을을 출력하게 끔 해주고 있습니다. : NASM 같은 경우 -f win32 와 같은 옵션을 제공하며 Cygwin 은 pei-i386 출력 포맷을 제공한답니다. 4. 런타임 라이브러리 여러분이 OS 코드를 작성할 때 가장 중요한 부분은 libc 라 불리는 런타임 라이브러리를 재작성하는 것입니다. 왜냐하면 런타임 라이브러리는 대부분 운영체제에 의존적인(OS-dependent) 컴파일러 패키지이기 때문입니다. : C 의 런타임 라이브러리(RTL : Run-Time Library)는 외부적인 면에서 이식성 있는 프로그램을 작성할 수 있도록 충분한 기능을 제공하지만, 내부적인 작업은 OS 에 의존적인 면이 있습니다. 사실, 컴파일러 회사(vendor)들은 같은 운영체제 상에서도 서로 다른 런타임 라이브러리를 사용하곤 합니다. : Microsoft Visual C++ 은 디버그/멀티-쓰레드/DLL 에 대해 서로 다른 라이브러리를 제공하고, 오래된 MS-DOS 컴파일러는 6가지의 다른 메모리 모델에 대한 런타임 라이브러리를 제공합니다. 여러분들은 "ISO C 표준" 에 따라 라이브러리를 작성하는데 초점을 맞추어야 하는데, 그 이유는 그렇게 라이브러리를 작성하는 것이 여러분들의 OS 로 프로그램들을 포팅하는 작업을 수월하게 만들기 때문입니다. 만약 여러분들이 (ISO C 표준안을 따르지 않는) 비표준 라이브러리 를 작성하게 된다면 여러분들이 포팅하고자 하는 어떤 어플리케이션이든지 다시 작성해야 될 것입니다. : 표준적인 라이브러리 함수를 정의한다면 오픈소스 어플리케이션을 바로 포팅하기가 더 수월해 질 것입니다. (% edward : 표준이란것은 나름대로 타당한 이유가 있어서 만들어진 것입니다. 별다른 이유가 없다면 따라 주는것이 좋겠지요.) 라이브러리의 환경이 여러분들이 개발하고자 하는 환경과 비슷하다면 이미 존재하는 임플리멘테이션에 대한 소스코드를 그 대로 사용할 수 있게 되고, 이는 라이브러리 코드를 작성하는 일을 좀더 수월하게 된다는 의미입니다. (% edward : 임플리멘테이션을 "구현"이라고 번역하지 않았냐고 머라고 한다면 그게 나름대로 "구현"이란 단어로 표현하기 애매한 부분이 너무나도 많은 것 같아서 입니다. 자세한 내용은 ISO-C 언어 표준에 관한 Committee Draft WG14/N869 에 있는 용어정리 부분을 삽입 하겠습니다. ISO/IEC 9899:1999 C Language Standard 문서를 구할 수 있다면 한번쯤 읽어보는것도 그다지 나쁘지는 않을 듯 싶네요. ==================================================================== implementation a particular set of software, running in a particular translation environment under particular control options, that performs translation of programs for, and supports execution of functions in, a particular execution environment ==================================================================== ) 그리고 OS 와 플랫폼에 대해 독립적인 많은 C 함수가 있습니다 : 예를들면 와 는 바로 복사해서 쓸수가 있죠. 반대로 여러분의 OS 를 제작하는데 있어 컴파일러에서 제공해주어야 하지만 그렇지 못한 경우의 함수들도 있습니다. : 예를들면 많은 도스 기반의 컴파일러는 PC 의 BIOS 에 접근할 수 있게 해주는 헤더 파일을 제공합니다. 여러분들이 커널에서 VM86 모니터를 작성하지 않는다면 BIOS 함수를 직접적으로 호출할 수는 없습니다. 하지만 어떤 함수들은 C 표준 라이브러리로 확장된 것일수도 있는데, 예를들면 "_biosdisk()"와 같이 함수 이름 앞에 언더스코어(_) 문자를 포함하는 것들이 그렇죠. 그런 함수들이 필요하다면 언더스코어 문자로 시작하는 이름을 부여하면 되므로 여러분들이 이러한 확장을 구현할 의무가 있는것은 아니지만 여러분들이 바란다면 자신만의 확장된 함수를 만들수도 있습니다. 다른 C 라이브러리 함수로는 커널을 지원하는데 의존적인 것들도 있습니다. : 는 현재 파일 시스템의 특성에 의존하게 되며, printf() 조차도 출력을 위한 대상이 필요하다. (% edward : 제 기억이 맞다면 표준 출력이라고만 되어있지 그것이 화면으로 출력해야 한다 라는건 아닌걸로 알고 있습니다.) printf() 에 대해서 조금 더 이야기 해보자면 대부분의 오픈소스 C 라이브러리 임플리멘테이션(implementation)은 일반적인 printf() 엔진을 정의하는데, 몇몇 기능에 따라 서로 다른 많은 함수들이 필요하기 때문입니다. 이 함수에 대한 버젼에는 printf(), fprintf(), sprintf(), vprintf(), wprintf(), vwprintf()등이 있습니다. 여러분들은 이 common engine 소스를 이용하여 스스로에게 필요한 용도로 사용해야 하거나 common engine 을 에뮬레이트 해야 합니다. : 그러기 위해서는 format string 과 format string의 출력을 함수나 buffered stream 과 같은 추상적인 인터페이스 보내기 위한 매개변수 리스트를 지원하는 함수를 작성해야 합니다. 사용자 어플리케이션을 작성하거나 포팅할 때 완전한 런타임 라이브러리가 가장 유용한 방법일 지라도 커널에서 런타임 라이브러리를 지원하는것 또한 편리한 방법이 될 수 있습니다. strcpy() 나 malloc() 처럼 일반적으로 사용되는 루틴을 포함하는 것은 커널 코드를 쉽고 빠르게 작성할 수 있게 도와주며 커널을 작게 만드는 좋은 결과를 낼 수 있습니다. 왜냐하면 자주 사용되는 루틴은 한번만 포함하면 되니까요. 드라이버 개발자에게도 바이너리에 일일이 자주 사용하게 되는 루틴을 포함하지 않게 할 수 있답니다. 5. 운영체제 구체적 지원 커널개발을 위한 언어로 볼때 C 가 완벽한 언어는 아닙니다. : 명백하게 따지자면 특정 머신의 특징에 대해서 접근하기 위한 표준적인 방법이 없다는데 그 이유가 있겠죠. 이는 C 언어가 종종 인라인 어셈블리(inline assembly)에 의존할 필요가 있으며 어셈블리의 코드부분과 C 언어로 작성된 코드를 컴파일하여 생성된 결과물들을 링크해야 하는 문제가 있다는 것 입니다. 인라인 어셈블리는 C 함수의 부분에 어셈블리 코드를 작성하는 것을 말하며 C 함수에서 어셈블리 언어로 작성된 변수들을 엑세스 할 수 있습니다 : 예를들면 컴파일러에 의해 생성된 코드 사이에 여러분들이 작성한 코드를 삽입 하는 것이 되겠지요. (% edward : 인라인 어셈블리란 c 언어 코드내에 어셈블리 언어를 사용하여 프로그램을 작성하는 것 입니다. 저는 나름대로 그렇게 생각하고 있는데 원래 저자가 거꾸로 써놓은 거 같아서 바로 잡았습니다. 허나 제가 잘못 알고 있는 것 일 수도 있으니 오류에 대해서는 메일을 보내주세요.) 인라인 어셈블리는 다양한 컴파일러에서 지원을 합니다. 비록 Intel Syntax 기반에서는 Visual C++ 이나 Borland C++ 이 더 많이 알려지긴 했지만 만약 여러분들이 AT&T Syntax 기반을 선택한다면 gcc 는 PC 컴파일러 중에서는 최고입니다. Visual C++ 이나 Borland C++ 의 인라인 어셈블러는 나머지 컴파일러에 대해서 완벽하게 통합적이지 않습니다. 하지만 gcc 의 더 난해한 Syntax 를 사용한다면 C 코드상에 어셈블러 블럭을 삽입한다거나 하는 등의 C 표현도 허용하며 이는 어떤 환경을 위한 결과물 또한 작성할 수 있습니다. 결과적으로 gcc의 어셈블리는 Borland 나 Microsoft 의 컴파일러 보다 더 최적화되고 통합적입니다. : 예를 든다면, gcc 는 어셈블리 블락의 결과에 따라 레지스터들을 수정하는 등의 지원을 합니다. 만약 커널 시스템콜을 호출하기 위해 소프트웨어 인터럽트를 한다면 유저모드에 대해서도 약간의 어셈블리 코드는 필요합니다. 그리고 MS-DOS 라이브러리 처럼 C 라이브러리 코드를 직접적으로 인터럽트 호출하거나 Windows NT 의 ntdll.dll 처럼 각각의 호출이나 링크를 위한 함수와 분리된 라이브러리를 만들 때도 필요합니다. OS 에 대해 의존적인 인터페이스를 갖는 언어에 대해 독립적인 라이브러리(Language-independent Library)를 만들어 둔다면 같은 OS 라이브러리를 사용하여 다른 언어를 사용하여 프로그램 할 수도 있습니다. 이는 많은 사람들이 C 의 바인딩을 허용하지 않는 C 가 아닌 다른언어로 여러분들의 OS 에서 동작하는 프로그램을 작성할 수가 있게 됩니다. (% edward : 이 점은 OS 개발을 생각하고 있는 사람이라면 가장 신경을 써야 될 부분이라고 생각합니다. 아무리 잘 만들어진 OS 라도 쓸만한 APP 가 없다면 유저입장에서 그것만큼 쓸모없는 OS 도 없을테니까요 ...) 6. C++ 커널 (C++ in the Kernel) C++ 로 커널을 작성한다는데 대해서는 많은 견해가 있습니다. : 몇몇 사람들이 C++ 로 운영체제를 작성하는데 반해 대부분의 리눅스 커널 코더들은 C++ 에는 관심이 없어보입니다. 저도 개인적으로는 C 언어를 사용합니다만 여러분들이 C++ 을 사용할 수 있다면 선택하지 않을 이유는 없다고 보입니다. 여러분들이 C++ 로 커널을 작성하기 위해서는 framework를 위한 코드를 조금 더 작성해야 할 필요가 있다는 것입니다. 그리고 필수적으로 지원해야할 코드를 작성할 것이 아니라면 C++ 의 몇 가지 특성을 제거해야 합니다. 우선적으로 new 와 delete 동작을 하는 코드가 필요합니다. 이는 이미 malloc() 이나 free() 에 대해서 코드를 작성해보았다면 쉽게 해결이 가능합니다 : new 와 delete 는 각각 malloc 과 free 를 호출하는 한 줄짜리 함수가 될 수 있습니다. 만약 여러분들이 클래스에 대한 전역 인스턴스를 이용하기를 원한다면 그에 대한 각각의 생성자를 호출하기 위한 시작 루틴을 삽입해야 할 것입니다. 이 방법에 있어서는 컴파일러 마다 다르게 되는데 여기서 가장 좋은 방법은 여러분들이 사용할 컴파일러의 런타임 라이브러리에서 이러한 일들을 어떻게 처리하고 있는가 하는걸 알아보는 것이 되겠죠. 예를 들어 crt0.c 와 같은 이름을 갖는 파일을 분석해보는 일을 하는겁니다. 아마도 atexit() 함수와 비슷한걸 구현 해야 될 것인데 그 이유는 C++ 컴파일러는 프로그램을 종료할때 전역 객체에 대한 소멸자를 호출하기 위해서 atexit() 함수를 사용하게 될 듯하기 때문입니다. 만약 커널에서 try/catch 를 사용하기를 바란다면 반드시 여러분들이 사용할 컴파일러에서 그것들을 사용할 수 있게 끔 해주는 구현부가 필요할 것입니다. 이 작업은 상당부분 여러분들이 사용하고자 하는 컴파일러에 의존적인 부분이며 어떤 운영체제에 어떤 컴파일러를 사용하느냐에 따라 달라지겠죠. 여러분들의 커널 개발에서 위의 두 가지 예외 처리와 거대한 가상 클래스에 대한 부분은 배제 했으면 하는 바입니다. 예외 처리를 하려면 불 필요한 추가적인 작업들이 많아지고, 가상적인 함수들에 대한 작업을 해야하는데 다소 최적화 부분에서는 그다지 좋지 않습니다. 그리고 이점을 기억해두세요 ... 여러분들의 커널은 약간의 디자인 부분에서의 손실을 감수하더라도 가능한한 효율적인것이 좋다고 생각합니다. (% edward : 제가 C++ 에 대해서는 전혀 공부해 본 바가 없어서 오류가 많을지도 모르겠습니다. 그리고 원저자가 말한 OS 디자인과 효율적인 면에 대한 이야기도 그리 반감이 가진 않는군요. MINIX 와 LINUX 의 예를 잘 보면 그다지 잘못된 내용도 아니라고 봅니다. 매우 적절한 예는 아닐테지만요 ^^) 7. 글을 마치면서 C와 같은 고급 언어에서 OS를 작성한다는 것은 전체적으로 어셈블리와 같은 언어로 코딩하는 것 보다는 훨씬 더 생산적인 면이 있습니다. 물론 속도 면에서 앞서가고자 한다면 어셈블리 언어를 사용하는것이 하나의 방법이 될 수 도 있습니다. (% edward : 늘 당부하는 말이지만 어설픈 assembly 언어로 최적화를 하려고 했다가는 c 언어로 작성한 것 보다 못한 경우가 많으니 어셈블리 언어로 코드를 작성할 시에는 둘의 코드를 비교해보고 퍼포먼스 테스트를 해보는 것이 필수입니다.) 또한 어셈블리언어나 다른 언어들 보다는 여러가지 면에서 상대적으로 쉽게 커널코드를 작성할 수 있는 gcc 같은 자유롭게 이용가능한 컴파일러도 있습니다. 그리고 C를 사용해 OS를 개발하는것은 오랜 개발기간동안 상당한 이점이 있을 것입니다. ======================================================================== * edward 의 문서 작성후기 이번에도 실패작 같습니다. -_-; 죄송합니다. 별로 도움이 되지 못하는 문서인듯 싶습니다. 번역도 전혀 마음에 안들구요. 게다가 단순히 이 내용만 가지고는 초보자들이 이해할 수 없는 부분도 꽤나 많은 것 같습니다. ======================================================================== ======================================================================== * Change Log (bout Documentation) - v 0.0.2 (2000.00.00) ========================================================================