Project1: Threads Project1: 스레드

In this assignment, we give you a minimally functional thread system. Your job is to extend the functionality of this system to gain a better understanding of synchronization problems. You will be working primarily in the threads directory for this assignment, with some work in the devices directory on the side. Compilation should be done in the threads directory. Before you read the description of this project, you should at least skim the material Synchronization.
이 과제에서는 최소한의 기능을 갖춘 스레드 시스템을 제공합니다. 여러분의 임무는 이 시스템의 기능을 확장하여 동기화 문제를 더 잘 이해하는 것입니다. 이 과제를 위해 주로 threads 디렉터리에서 작업하고, 일부 작업은 devices 디렉터리에서 수행하게 될 것입니다. 컴파일은 threads 디렉터리에서 수행해야 합니다. 이 프로젝트에 대한 설명을 읽기 전에 최소한 동기화 자료를 훑어보셔야 합니다.

Background 배경

Understanding Threads 스레드 이해

The first step is to read and understand the code for the initial thread system. Pintos already implements thread creation and thread completion, a simple scheduler to switch between threads, and synchronization primitives (semaphores, locks, condition variables, and optimization barriers).
첫 번째 단계는 초기 스레드 시스템의 코드를 읽고 이해하는 것입니다. 핀토스는 이미 스레드 생성 및 스레드 완료, 스레드 간 전환을 위한 간단한 스케줄러, 동기화 기본 요소(세마포어, 잠금, 조건 변수 및 최적화 배리어)를 구현하고 있습니다.

Some of this code might seem slightly mysterious. If you haven't already compiled and run the base system, as described in the introduction you should do so now. You can read through parts of the source code to see what's going on. If you like, you can add calls to printf() almost anywhere, then recompile and run to see what happens and in what order. You can also run the kernel in a debugger and set breakpoints at interesting spots, single-step through code and examine data, and so on.
이 코드 중 일부는 다소 난해해 보일 수 있습니다. 아직 기본 시스템을 컴파일하고 실행하지 않았다면 소개에 설명된 대로 지금 컴파일해야 합니다. 소스 코드의 일부를 읽으면서 무슨 일이 일어나고 있는지 확인할 수 있습니다. 원하는 경우 거의 모든 곳에 printf() 호출을 추가한 다음 다시 컴파일하고 실행하여 어떤 일이 어떤 순서로 발생하는지 확인할 수 있습니다. 디버거에서 커널을 실행하여 흥미로운 지점에 중단점을 설정하고, 코드를 한 단계씩 실행하여 데이터를 검사하는 등의 작업을 수행할 수도 있습니다.

When a thread is created, you are creating a new context to be scheduled. You provide a function to be run in this context as an argument to thread_create(). The first time the thread is scheduled and runs, it starts from the beginning of that function and executes in that context. When the function returns, the thread terminates. Each thread, therefore, acts like a mini-program running inside Pintos, with the function passed to thread_create() acting like main().
스레드가 생성되면 스케줄링할 새 컨텍스트가 만들어집니다. 이 컨텍스트에서 실행할 함수를 thread_create()의 인수로 제공합니다. 스레드가 처음 예약되어 실행되면 해당 함수의 시작 부분부터 시작하여 해당 컨텍스트에서 실행됩니다. 함수가 반환되면 스레드는 종료됩니다. 따라서 각 스레드는 핀토스 내부에서 실행되는 미니 프로그램처럼 작동하며, thread_create()에 전달된 함수는 main()처럼 작동합니다.

At any given time, exactly one thread runs and the rest, if any, become inactive. The scheduler decides which thread to run next. (If no thread is ready to run at any given time, then the special idle thread, implemented in idle(), runs.) Synchronization primitives can force context switches when one thread needs to wait for another thread to do something.
특정 시간에 정확히 하나의 스레드만 실행되고 나머지는 비활성 상태가 됩니다. 스케줄러는 다음에 실행할 스레드를 결정합니다. (특정 시간에 실행할 준비가 된 스레드가 없는 경우 idle로 구현된 특수 idle() 스레드가 실행됩니다). 동기화 프리미티브는 한 스레드가 다른 스레드가 어떤 작업을 수행할 때까지 기다려야 할 때 컨텍스트 전환을 강제할 수 있습니다.

The mechanics of a context switch are in thread_launch() in threads/thread.c (You don't have to understand it.) It saves the state of the currently running thread and restores the state of the thread we're switching to.
컨텍스트 전환의 메커니즘은 thread_launch()에 있는 threads/thread.c에 있습니다.

Using the GDB debugger, slowly trace through a context switch to see what happens (see GDB). You can set a breakpoint on schedule() to start out, and then single-step from there. Be sure to keep track of each thread's address and state, and what procedures are on the call stack for each thread. You will notice that when one thread executes iret in do_iret(), another thread starts running.
GDB 디버거를 사용하여 컨텍스트 전환을 통해 천천히 추적하여 어떤 일이 발생하는지 확인합니다(GDB 참조). schedule()에 중단점을 설정하여 시작하고 거기서부터 한 단계씩 진행할 수 있습니다. 각 스레드의 주소와 상태, 각 스레드의 호출 스택에 어떤 프로시저가 있는지 추적해야 합니다. 한 스레드가 iret에서 do_iret()를 실행하면 다른 스레드가 실행되기 시작하는 것을 알 수 있습니다.

Warning: In Pintos, each thread is assigned a small, fixed-size execution stack just under 4 kB in size. The kernel tries to detect stack overflow, but it cannot do so perfectly. You may cause bizarre problems, such as mysterious kernel panics, if you declare large data structures as non-static local variables, e.g. int buf[1000];. Alternatives to stack allocation include the page allocator and the block allocator (see Memory Allocation.)
경고: 핀토에서는 각 스레드에 4KB 미만의 작은 고정 크기 실행 스택이 할당됩니다. 커널은 스택 오버플로를 감지하려고 시도하지만 완벽하게 감지할 수는 없습니다. 큰 데이터 구조를 비정적 로컬 변수로 선언하면 커널 패닉과 같은 기이한 문제가 발생할 수 있습니다(예: int buf[1000];). 스택 할당의 대안으로는 페이지 할당자와 블록 할당자가 있습니다(메모리 할당 참조).

Source Files 소스 파일

Here is a brief overview of the files in the threads, and include/threads directory. You will not need to modify most of this code, but the hope is that presenting this overview will give you a start on what code to look at.
다음은 threads 및 include/threads 디렉터리에 있는 파일에 대한 간략한 개요입니다. 이 코드의 대부분은 수정할 필요가 없지만, 이 개요를 제시함으로써 어떤 코드를 살펴봐야 할지에 대한 시작점이 될 수 있기를 바랍니다.

threads codes
스레드 코드

• loader.S, loader.h

  The kernel loader. Assembles to 512 bytes of code and data that the PC BIOS loads into memory and which in turn finds the kernel on disk, loads it into memory, and jumps to bootstrap() in start.S. You should not need to look at this code or modify it. start.S does basic setup needed for memory protection and jump into the 64bit long mode. Unlike the loader, this code is actually part of the kernel.
  커널 로더. 512바이트의 코드와 데이터로 구성되며, PC BIOS가 메모리로 로드하고 디스크에서 커널을 찾아 메모리에 로드한 다음 start.S에서 bootstrap()로 점프합니다. 이 코드를 보거나 수정할 필요는 없습니다. start.S는 메모리 보호에 필요한 기본 설정을 수행하고 64비트 긴 모드로 이동합니다. 로더와 달리 이 코드는 실제로 커널의 일부입니다.

• kernel.lds.S

  The linker script used to link the kernel. Sets the load address of the kernel and arranges for start.S to be near the beginning of the kernel image. Again, you should not need to look at this code or modify it, but it's here in case you're curious.
  커널을 연결하는 데 사용되는 링커 스크립트입니다. 커널의 로드 주소를 설정하고 start.S가 커널 이미지의 시작 부분 근처에 위치하도록 정렬합니다. 다시 말하지만, 이 코드를 보거나 수정할 필요는 없지만 궁금한 경우를 대비하여 여기에 설명되어 있습니다.

• init.c, init.h

  Kernel initialization, including main(), the kernel's main program. You should look over main() at least to see what gets initialized. You might want to add your own initialization code here.
  커널 초기화, main(), 커널의 메인 프로그램. 최소한 main()를 살펴보고 무엇이 초기화되는지 확인해야 합니다. 여기에 고유한 초기화 코드를 추가할 수도 있습니다.

• thread.c, thread.h

  Basic thread support. Much of your work will take place in these files. thread.h defines struct thread, which you are likely to modify in all four projects. See Threads for more information.
  기본 스레드 지원. 대부분의 작업은 이 파일에서 이루어집니다. thread.h는 네 프로젝트 모두에서 수정할 가능성이 높은 구조체 스레드를 정의합니다. 자세한 내용은 스레드를 참조하세요.

• palloc.c, palloc.h

  Page allocator, which hands out system memory in multiples of 4 kB pages. See Page Allocator for more information.
  페이지 할당기는 시스템 메모리를 4kB 페이지의 배수로 나눠주는 페이지 할당기입니다. 자세한 내용은 페이지 할당기를 참조하세요.

• malloc.c, malloc.h

  A simple implementation of malloc() and free() for the kernel. See Block Allocator for more information.
  커널에 malloc() 및 free()를 간단하게 구현할 수 있습니다. 자세한 내용은 블록 얼로케이터를 참조하세요.

• interrupt.c, interrupt.h

  Basic interrupt handling and functions for turning interrupts on and off.
  기본 인터럽트 처리 및 인터럽트를 켜고 끄는 기능.

• intr-stubs.S, intr-stubs.h

  Assembly code for low-level interrupt handling.
  로우레벨 인터럽트 처리를 위한 어셈블리 코드입니다.

• synch.c, synch.h

  Basic synchronization primitives: semaphores, locks, condition variables, and optimization barriers. You will need to use these for synchronization in all four projects. See Synchronization for more information.
  기본 동기화 기본 요소: 세마포어, 잠금, 조건 변수, 최적화 배리어. 네 가지 프로젝트 모두에서 동기화를 위해 이러한 기본 요소를 사용해야 합니다. 자세한 내용은 동기화를 참조하세요.

• mmu.c, mmu.h

  Functions for x86-64 page table operations. You will look this file closer after the lab1.
  x86-64 페이지 테이블 작업용 함수. 실습1 이후에 이 파일을 자세히 살펴보겠습니다.

• io.h

  Functions for I/O port access. This is mostly used by source code in the devices directory that you won't have to touch.
  I/O 포트 액세스를 위한 함수입니다. 이 함수는 대부분 devices 디렉터리의 소스 코드에서 사용하므로 직접 건드릴 필요가 없습니다.

• vaddr.h, pte.h

  Functions and macros for working with virtual addresses and page table entries. These will be more important to you in project 3. For now, you can ignore them.
  가상 주소 및 페이지 테이블 항목 작업을 위한 함수 및 매크로입니다. 이는 프로젝트 3에서 더 중요해질 것입니다. 지금은 무시해도 됩니다.

• flags.h

  Macros that define a few bits in the x86-64 flags register. Probably of no interest.
  x86-64 flags 레지스터에서 몇 비트를 정의하는 매크로입니다. 아마 관심 없을 겁니다.

devices codes
장치 코드

The basic threaded kernel also includes these files in the devices directory:
기본 스레드 커널은 devices 디렉토리에 이러한 파일도 포함합니다:

• timer.c, timer.h
타이머.c, 타이머.h

  System timer that ticks, by default, 100 times per second. You will modify this code in this project.
  기본적으로 초당 100회 틱하는 시스템 타이머입니다. 이 프로젝트에서 이 코드를 수정합니다.

• vga.c, vga.h

  VGA display driver. Responsible for writing text to the screen. You should have no need to look at this code. printf() calls into the VGA display driver for you, so there's little reason to call this code yourself.
  VGA 디스플레이 드라이버. 화면에 텍스트를 쓰는 일을 담당합니다. 이 코드를 볼 필요가 없습니다. printf()가 VGA 디스플레이 드라이버를 대신 호출하므로 이 코드를 직접 호출할 이유가 거의 없습니다.

• serial.c, serial.h

  Serial port driver. Again, printf() calls this code for you, so you don't need to do so yourself. It handles serial input by passing it to the input layer (see below).
  직렬 포트 드라이버. 다시 말하지만, printf()가 이 코드를 대신 호출하므로 직접 작성할 필요가 없습니다. 이 코드는 직렬 입력을 입력 레이어로 전달하여 처리합니다(아래 참조).

• block.c, block.h

  An abstraction layer for block devices, that is, random-access, disk-like devices that are organized as arrays of fixed-size blocks. Out of the box, Pintos supports two types of block devices: IDE disks and partitions. Block devices, regardless of type, won't actually be used until project 2.
  블록 디바이스, 즉 고정 크기 블록의 배열로 구성된 랜덤 액세스 디스크와 같은 디바이스를 위한 추상화 계층입니다. Pintos는 기본적으로 두 가지 유형의 블록 장치를 지원합니다: IDE 디스크와 파티션. 블록 장치는 유형에 관계없이 프로젝트 2까지는 실제로 사용되지 않습니다.

• ide.c, ide.h

  Supports reading and writing sectors on up to 4 IDE disks.
  최대 4개의 IDE 디스크에서 섹터 읽기 및 쓰기를 지원합니다.

• partition.c, partition.h

  Understands the structure of partitions on disks, allowing a single disk to be carved up into multiple regions (partitions) for independent use.
  디스크의 파티션 구조를 이해하여 하나의 디스크를 여러 영역(파티션)으로 분할하여 독립적으로 사용할 수 있습니다.

• kbd.c, kbd.h

  Keyboard driver. Handles keystrokes passing them to the input layer (see below).
  키보드 드라이버. 키 입력을 처리하여 입력 레이어로 전달합니다(아래 참조).

• input.c, input.h

  Input layer. Queues input characters passed along by the keyboard or serial drivers.
  입력 레이어. 키보드 또는 직렬 드라이버가 전달한 입력 문자를 대기열에 넣습니다.

• intq.c, intq.h

  Interrupt queue, for managing a circular queue that both kernel threads and interrupt handlers want to access. Used by the keyboard and serial drivers.
  커널 스레드와 인터럽트 핸들러가 모두 액세스하려는 순환 큐를 관리하기 위한 인터럽트 큐입니다. 키보드 및 직렬 드라이버에서 사용됩니다.

• rtc.c, rtc.h

  Real-time clock driver, to enable the kernel to determine the current date and time. By default, this is only used by thread/init.c to choose an initial seed for the random number generator.
  실시간 시계 드라이버로, 커널이 현재 날짜와 시간을 확인할 수 있도록 합니다. 기본적으로 이 드라이버는 난수 생성기의 초기 시드를 선택하기 위해 thread/init.c에서만 사용됩니다.

• speaker.c, speaker.h

  Driver that can produce tones on the PC speaker.
  PC 스피커에서 톤을 생성할 수 있는 드라이버입니다.

• pit.c, pit.h

  Code to configure the 8254 Programmable Interrupt Timer. This code is used by both devices/timer.c and devices/speaker.c because each device uses one of the PIT's output channel.
  8254 프로그래밍 가능 인터럽트 타이머를 구성하는 코드입니다. 이 코드는 각 장치가 PIT의 출력 채널 중 하나를 사용하기 때문에 devices/timer.c와 devices/speaker.c 모두에서 사용됩니다.

lib codes
lib 코드

Finally, lib and lib/kernel contain useful library routines. (lib/user will be used by user programs, starting in project 2, but it is not part of the kernel.) Here's a few more details:
마지막으로, lib와 lib/kernel에는 유용한 라이브러리 루틴이 포함되어 있습니다. (lib/user는 프로젝트 2부터 사용자 프로그램에서 사용되지만 커널의 일부가 아닙니다). 다음은 몇 가지 자세한 내용입니다:

• ctype.h, inttypes.h, limits.h, stdarg.h, stdbool.h, stddef.h, stdint.h, stdio.c, stdio.h, stdlib.c, stdlib.h, string.c, string.h

  A subset of the standard C library.
  표준 C 라이브러리의 하위 집합입니다.

• debug.c, debug.h

  Functions and macros to aid debugging. See Debugging Tools for more information.
  디버깅을 지원하는 함수 및 매크로. 자세한 내용은 디버깅 도구를 참조하세요.

• random.c, random.h

  Pseudo-random number generator. The actual sequence of random values will not vary from one Pintos run to another.
  의사 난수 생성기. 실제 난수 값의 순서는 핀토스 실행마다 달라지지 않습니다.

• round.h

  Macros for rounding. 반올림을 위한 매크로.

• syscall-nr.h

  System call numbers. Not used until project 2.
  시스템 호출 번호. 프로젝트 2까지는 사용되지 않습니다.

• kernel/list.c, kernel/list.h

  Doubly linked list implementation. Used all over the Pintos code, and you'll probably want to use it a few places yourself in project 1. We recommand you to skim this code before you start (especially comments in the header file.)
  이중 링크 목록 구현. 핀토스 코드 전체에 사용되며 프로젝트 1에서 몇 군데 직접 사용하고 싶을 것입니다. 시작하기 전에 이 코드를 훑어보는 것이 좋습니다(특히 헤더 파일에 있는 주석)."

• kernel/bitmap.c, kernel/bitmap.h

  Bitmap implementation. You can use this in your code if you like, but you probably won't have any need for it in project 1.
  비트맵 구현. 원하는 경우 코드에서 사용할 수 있지만 프로젝트 1에서는 필요하지 않을 것입니다.

• kernel/hash.c, kernel/hash.h

  Hash table implementation. Likely to come in handy for project 3.
  해시 테이블 구현. 프로젝트 3에서 유용하게 사용할 수 있을 것 같습니다.

• kernel/console.c, kernel/console.h, kernel/stdio.h
커널/콘솔.c, 커널/콘솔.h, 커널/stdio.h

  Implements printf() and a few other functions.
  printf() 및 기타 몇 가지 함수를 구현합니다.

Synchronization 동기화

Proper synchronization is an important part of the solutions to these problems. Any synchronization problem can be easily solved by turning interrupts off: while interrupts are off, there is no concurrency, so there's no possibility for race conditions. Therefore, it's tempting to solve all synchronization problems this way, but don't. Instead, use semaphores, locks, and condition variables to solve the bulk of your synchronization problems. Read the tour section on synchronization (see Synchronization) or the comments in threads/synch.c if you're unsure what synchronization primitives may be used in what situations.
적절한 동기화는 이러한 문제를 해결하는 데 있어 중요한 부분입니다. 모든 동기화 문제는 인터럽트를 끄면 쉽게 해결할 수 있습니다. 인터럽트가 꺼져 있는 동안에는 동시성이 없으므로 경쟁 조건이 발생할 가능성이 없습니다. 따라서 모든 동기화 문제를 이 방법으로 해결하고 싶을 수도 있지만, 그러지 마세요. 대신 세마포어, 잠금, 조건 변수를 사용하여 동기화 문제의 대부분을 해결하세요. 어떤 상황에서 어떤 동기화 프리미티브가 사용될 수 있는지 잘 모르겠다면 동기화에 대한 둘러보기 섹션(동기화 참조)이나 threads/synch.c에 있는 주석을 읽어보세요.

In the Pintos projects, the only class of problem best solved by disabling interrupts is coordinating data shared between a kernel thread and an interrupt handler. Because interrupt handlers can't sleep, they can't acquire locks. This means that data shared between kernel threads and an interrupt handler must be protected within a kernel thread by turning off interrupts.
핀토스 프로젝트에서 인터럽트를 비활성화하면 가장 잘 해결되는 유일한 종류의 문제는 커널 스레드와 인터럽트 핸들러 간에 공유되는 데이터를 조정하는 것입니다. 인터럽트 핸들러는 잠자기 상태가 될 수 없으므로 잠금을 획득할 수 없습니다. 즉, 커널 스레드와 인터럽트 핸들러 간에 공유되는 데이터는 인터럽트를 해제하여 커널 스레드 내에서 보호해야 합니다.

This project only requires accessing a little bit of thread state from interrupt handlers. For the alarm clock, the timer interrupt needs to wake up sleeping threads. In the advanced scheduler, the timer interrupt needs to access a few global and per-thread variables. When you access these variables from kernel threads, you will need to disable interrupts to prevent the timer interrupt from interfering.
이 프로젝트는 인터럽트 핸들러에서 약간의 스레드 상태만 액세스하면 됩니다. 알람 시계의 경우 타이머 인터럽트는 잠자는 스레드를 깨워야 합니다. 고급 스케줄러에서 타이머 인터럽트는 몇 가지 전역 및 스레드별 변수에 액세스해야 합니다. 커널 스레드에서 이러한 변수에 액세스할 때는 타이머 인터럽트가 간섭하지 못하도록 인터럽트를 비활성화해야 합니다.

When you do turn off interrupts, take care to do so for the least amount of code possible, or you can end up losing important things such as timer ticks or input events. Turning off interrupts also increases the interrupt handling latency, which can make a machine feel sluggish if taken too far.
인터럽트를 끌 때는 가능한 한 최소한의 코드만 사용하도록 주의하세요. 그렇지 않으면 타이머 틱이나 입력 이벤트와 같은 중요한 정보가 손실될 수 있습니다. 또한 인터럽트를 끄면 인터럽트 처리 지연 시간이 증가하므로 너무 오래 걸리면 컴퓨터가 느려질 수 있습니다.

The synchronization primitives themselves in synch.c are implemented by disabling interrupts. You may need to increase the amount of code that runs with interrupts disabled here, but you should still try to keep it to a minimum.
synch.c의 동기화 프리미티브 자체는 인터럽트를 비활성화하여 구현됩니다. 여기서 인터럽트를 비활성화한 상태에서 실행되는 코드의 양을 늘려야 할 수도 있지만, 그래도 최소한으로 유지해야 합니다.

Disabling interrupts can be useful for debugging, if you want to make sure that a section of code is not interrupted. You should remove debugging code before turning in your project. (Don't just comment it out, because that can make the code difficult to read.)
코드 섹션이 중단되지 않도록 하려는 경우 인터럽트를 비활성화하면 디버깅에 유용할 수 있습니다. 프로젝트를 제출하기 전에 디버깅 코드를 제거해야 합니다. (코드를 주석 처리하면 코드를 읽기 어려울 수 있으므로 그냥 제거하지 마세요.)

There should be no busy waiting in your submission. A tight loop that calls thread_yield() is one form of busy waiting.
제출에 바쁜 대기가 없어야 합니다. thread_yield()를 호출하는 타이트 루프는 바쁜 대기의 한 형태입니다.

Development Suggestions 개발 제안

In the past, many groups divided the assignment into pieces, then each group member worked on his or her piece until just before the deadline, at which time the group reconvened to combine their code and submit. This is a bad idea. We do not recommend this approach. Groups that do this often find that two changes conflict with each other, requiring lots of last-minute debugging. Some groups who have done this have turned in code that did not even compile or boot, much less pass any tests.
과거에는 많은 그룹이 과제를 여러 조각으로 나눈 다음 마감일 직전까지 각 그룹 구성원이 자신의 조각을 작업한 다음 그룹이 다시 모여 코드를 결합하여 제출했습니다. 이는 좋지 않은 방법입니다. 이 방법은 권장하지 않습니다. 이렇게 하는 그룹은 종종 두 가지 변경 사항이 서로 충돌하여 막판에 많은 디버깅이 필요한 경우가 많습니다. 이렇게 한 일부 그룹은 테스트를 통과하기는커녕 컴파일이나 부팅조차 되지 않은 코드를 제출하기도 했습니다.

Instead, we recommend integrating your team's changes early and often, using a source code control system such as git. This is less likely to produce surprises, because everyone can see everyone else's code as it is written, instead of just when it is finished. These systems also make it possible to review changes and, when a change introduces a bug, drop back to working versions of code.
대신 git와 같은 소스 코드 제어 시스템을 사용하여 팀의 변경 사항을 조기에 그리고 자주 통합하는 것이 좋습니다. 이렇게 하면 코드가 완성된 시점이 아니라 작성되는 동안 모든 사람이 다른 사람의 코드를 볼 수 있기 때문에 예상치 못한 문제가 발생할 가능성이 적습니다. 또한 이러한 시스템을 사용하면 변경 사항을 검토하고 변경으로 인해 버그가 발생하면 작동 중인 코드 버전으로 되돌릴 수 있습니다.

You should expect to run into bugs that you simply don't understand while working on this and subsequent projects. When you do, reread the appendix on debugging tools, which is filled with useful debugging tips that should help you to get back up to speed (see Debugging Tools). Be sure to read the section on backtraces (see Backtraces), which will help you to get the most out of every kernel panic or assertion failure.
이 프로젝트와 후속 프로젝트에서 작업하는 동안 이해하지 못하는 버그가 발생할 수 있습니다. 그럴 때는 유용한 디버깅 팁이 담긴 디버깅 도구에 대한 부록을 다시 읽어보세요(디버깅 도구 참조). 모든 커널 패닉 또는 어설션 실패를 최대한 활용하는 데 도움이 되는 백트레이스(백트레이스) 섹션도 꼭 읽어보세요.