Kernel/Gentoo Kernel Configuration Guide/ko

이 문서는 직접 커널 설정 개념을 소개하며 대부분의 일반 설정 과정의 함정을 낱낱이 파헤칩니다.

도입부
젠투에서는 커널 설정, 설치, 업그레이드 방식을 두가지 제공합니다. 하나는 자동 (genkernel) 그리고 다른 하나는 수동 입니다. 비록 자동 방식이 대부분 사용자에게 쉽겠지만, 상당수의 젠투 사용자들이 커널을 직접 설정하는 방법을 선택하는지에 대해서는 수많은 이유가 있습니다:


 * 1) 엄청난 유연성
 * 2) 작은 (커널) 크기
 * 3) 짧은 컴파일 시간
 * 4) 배움의 경험
 * 5) 극심한 귀차니즘
 * 6) 커널 설정에 대한 확실한 지식 확보 또는
 * 7) 완벽한 설정 처리

이 안내서에서는 자동 방식(genkernel)을 다루지 않습니다. 커널과 관련된 문제를 다루는데 genkernel을 원한다면 Genkernel 글에 집중하십시오.

이 안내서에서는 시작부터 끝날 때까지 직접 설정 과정을 문서화하지 않습니다. 설정 과정은 상식적으로 상당 범위를 다루며 시스템을 사용하는데 있어 비교적 고수준의 기술 지식을 요합니다. 대신 직접 설정의 개념 정도 소개하며 사용자 입장에서 대부분 빠지기 쉬운 함정을 자세하게 안내하겠습니다.

여기서, 사용자 여러분께서 이미 하드디스크(보통 아래 어딘가에)에 리눅스 커널 소스 코드의 압축을 해제했고, ncurses 메뉴 체계 기반을 통해 어느 정도 설정을 탐색하는 지식을 갖춘 상태에서 menuconfig 설정 유틸리티에 들어가는 방법을 알고 있다고 가정하겠습니다. 만약 이 단계의 사용자가 아니라면 도움이 될 다른 문서가 있으니 찾아보십시오. 다음 게시글을 읽고, 이 안내서로 돌아오시면 됩니다:


 * 커널 소스 코드 개요는 포티지 트리에 있는 커널 소스 코드 꾸러미 정보가 있습니다.
 * 커널 업그레이드는 커널 업그레이드 및 커널 전환 방법을 설명합니다.
 * 젠투 핸드북의 커널 설정 장에서는 커널 설치 방법을 다룹니다. 적당한 아키텍처를 선택하신 후 리눅스 커널 설정장을 들어가서 내용을 살펴보십시오.

기본
일반 과정은 실제로 꽤 단순합니다: 여러개의 옵션을, 각 메뉴와 하위 메뉴로 분류한 채로 나타나며, 원하는 하드웨어 지원 및 시스템과 관련된 커널 기능이 이미 선택한 상태입니다.

커널에는 기본 설정이 들어있는데 소스 코드 일부로 menuconfig를 처음 실행할 때 나타납니다. 기본 값은 보통 다양하고 분별성이 있는데, 대부분의 사용자가 기본 설정에서 바꾸는 설정 가지 수가 적음을 의미합니다. 이미 활성화한 커널의 기본 설정을 비활성화하기로 결정했다면 해당 옵션의 동작에 대해 정확하게 이해하고 있는지 확인하시고, 그 다음에 비활성화하십시오.

리눅스 커널 설정을 처음 진행하는 동안, 설정 목적은 보수적이어야 합니다. 너무 도전적이어서도 안되며 가능한 한 기본 설정의 수정은 최소화하십시오. 또한, 실제 시스템을 부팅할 수 있도록 개별적으로 처리할 시스템 설정 부분이 있음을 고려하십시오.

내장이냐 모듈이냐
대부분의 설정 옵션은 3 상태 입니다: 빌드하지 않는  옵션, 커널에 빌드하는   옵션, 모듈로 빌드하는   옵션이 될 수 있습니다. 모듈은 파일 시스템 상 외부에 저장하며, 내장 항목은 커널 이미지 자체에 직접 빌드합니다.

빌드에 포함 및 모듈화 개념간에는 중요한 차이점이 있습니다. 몇가지 예외를 들자면, 커널자체 에서는 시스템이 필요로 하는 외부 모듈을 불러오려 하지 않습니다. 모듈을 언제 불러올 지 말지는 사용자가 결정하도록 내버려둡니다. 시스템의 다른 나머지 부분이 요청시 불러오는 구조로 되어 있고 모듈을 자동으로 불러오는 유틸리티가 있지만 하드웨어 지원과 커널 기능을 커널에 포함하여 빌드하는 것이 좋습니다. 그러면 커널에서 언제 필요하든지간에 커널 기능과 하드웨어 지원 기능을 포함하고 있기 때문에 이 점을 인지할 수 있습니다. 이는 커널 기능에 로 설정하여 처리할 수 있습니다. 이렇게 관계되도록 설정하려면 커널에 펌웨어 지원을 포함하도록 해야합니다. 에서  옵션과   옵션을 설정하거나 다음처럼 설정하시면 됩니다:

나머지 설정 부분에 대해서는, 커널에 포함하여 빌드하는 옵션이 정말 필요합니다. 예를 들어 루트 분할 공간이이 btrfs 파일 시스템이라면 btrfs를 모듈로 빌드하면 부팅할 수 없습니다. 시스템에서는 루트 분할 공간에서 btrfs 모듈을 찾겠지만(루트 분할 공간에 모듈이 들어가 있음), btrfs 파일 시스템 기능 지원을 불러오기 전에는 루트 분할 공간을 탐색할 루 없습니다! btrfs를 포함하여 빌드하지 않으면 초기화 과정에서 루트 장치를 찾는데 실패합니다.

하드웨어 지원
시스템의 아키텍처 형식을 발견하기 전에, 설정 유틸리티는 시스템에 실제로 나타나는 하드웨어가 무엇인지 발견하려 들지도 않습니다. 일부 하드웨어 지원에 대한 기본 값만 있으므로 사용자는 각 시스템의 하드웨어 설정과 관련된 설정 옵션을 찾아 분명하게 설정해야합니다.

적당한 설정 옵션을 선택하려면 컴퓨터 안에 붙어있거나 연결한 구성품에 대한 지식이 필요합니다. 대부분의 경우 이러한 구성품은 시스템의 뚜껑을 열지 않고도 알아볼 수 있습니다. 대부분의 내부 구성품에 대해서는 사용자가 판매 제품 이름이나 모델보다는 각 장치에 붙어있는 칩셋을 식별해야합니다. 대부분의 확장 카드는 자체 브랜드 이름을 달고 판매하지만, 다른 제조사의 칩셋을 사용합니다.

어떤 커널 설정 옵션을 사용할 지 사용자가 결정하도록 도와주는 유틸리티가 있습니다. ( 꾸러미 구성 바이너리)는 PCI 기반, AGP 기반 하드웨어를 식별하는데, 이 정보에는 마더보드 자체에 붙인 구성품 정보도 들어있습니다. lsusb ( 꾸러미 구성 바이너리)는 시스템의 USB 포트에 연결한 다양한 장치를 식별합니다.

하드웨어 세계의 다양한 표준화 양상 때문에 혼동되는 상황입니다. 사용자가 상당히 다른 기본 설정을 선택하기 전에는 IDE 하드 디스크는 PS/2 또는 USB 키보드 및 마우스처럼 그냥 동작해야 합니다. 기본 VGA 디스플레이 기능 지원도 역시 포함되어 있습니다. 그러나 이더넷 어댑터 같은 장치는 거의 표준화되어 있지 않습니다. 이런 장치 사용자들은 이더넷 칩셋을 확인해야 하며, 카드별로 적당한 하드웨어 지원 드라이버를 선택하여 네트워크에 접근할 수 있도록 해야 합니다.

게다가, 어떤 구성 요소가 기본 설정으로 그냥 잘 동작하기만 한다면, 시스템의 완벽한 잠재성능을 끌어 올리기 위해 더욱 특별한 옵션을 선택해야합니다. 예를 들어 적당한 IDE 칩셋을 활성화하지 않았다면 IDE 하드 디스크는 매우 느리게 동작합니다.

커널 기능
또한 하드웨어 지원에 있어, 사용자 여러분은 커널에서 필요한 소프트웨어 기능을 고려해야 합니다. 이런 기능 중 중요한 한가지는 파일 시스템 지원입니다. 사용자는 하드디스크에서 사용 중인 파일 시스템 지원 기능과 외장 장치에서 사용할 파일 시스템 지원 기능을 활성화해야 합니다(예: USB 장치의 VFAT).

다른 일반 소프트웨어 기증의 예로 고급 네트워크 기능이 있습니다. 라우팅 또는 방화벽 동작을 수행한다면 관련 설정 항목을 커널 설정에 포함해야합니다.

준비됐죠?
이제 개념을 소개했으니 시스템 하드웨어를 식별하고, menuconfig 인터페이스로 탐색한 다음, 시스템에 필요한 커널 옵션을 선택하는 과정의 시작은 쉬울겝니다.

이 안내서의 나머지는 일반적으로 혼동하기 쉬운 부분이며, 사용자가 빠져들기 쉬운 일반적인 문제를 피해가는 방법에 대해 알려드립니다. 잘 되시길!

SATA 디스크는 SCSI 입니다
최신 데스크톱 시스템에는 저장장치(하드 디스크 및 CD/DVD 드라이브)를 IDEen (리본 케이블) 방식이 아닌 직렬 ATAen 버스에 연결합니다.

리눅스에서의 SATA 기능 지원은 SCSI 하위 시스템에 배치한 libata 참조 계층에서 구현했습니다. 이런 이유로 SATA 드라이버는 설정의 SCSI 드라이버 섹션에서 나타납니다. 게다가 시스템 저장장치는 SCSI 장치처럼 다루는데 SCSI 디스크/CD롬 장치 역시 필요하다는 이야기입니다. 첫번째 SATA 하드 디스크는 고 첫번째 SATA CD/DVD 드라이브는 이 됩니다.

비록 이들 드라이버의 주된 관리 대상이 SATA 컨트롤러지만 libata는 SATA 전용으로 설계하지는 않았습니다. 모든 일반 IDE 드라이버 역시 libata에 포팅합니다. 그리고 지금은 IDE 사용자에게도 적용할 예정입니다.

IDE 칩셋과 DMA
SATA 도입에도 불구, IDE 장치는 여전히 일반적으로 사용중이며 수많은 시스템에 달려있습니다. IDE는 거의 일반 기술이나 다름없지만, 이렇듯 리눅스에서는 대부분의 모든 IDE 컨트롤러를 컨트롤러별 옵션을 따로 선택하지 않고도 특별하게 지원합니다.

그러나 IDE는 퇴물 기술이고, 초기 프로그램 처리한 입출력 형태에 있어, 최신 저장 장치로의 신속한 접근을 위해 필요한 전송률을 제공할 수 없습니다. 일반 IDE 드라이버는 느린 데이터 전송률을 보였고 디스크에서 데이터를 전송하는 동안 상당량의 CPU 사용율을 보여 PIO 전송 모드 동작에 제한이 있었습니다.

1995년 이전 생산 시스템을 다루지 않는 한 IDE 컨트롤러에서는 Direct Memory Access (DMA)라는 대안 전송 모드를 지원합니다. DMA는 상당히 빨라 데이터 전송을 처리하는동안 CPU 가용성에 상당한 영향을 줍니다. IDE 디스크를 활용하는 동안 시스템이 정상 성능이 제대로 안나와 문제가 있다면, DMA를 사용하지 않아 활성화해야 할 상황임을 의미합니다.

IDE 디스크가 libata를 사용하지 않는다면 활성화하십시오. 다음 명령은 DMA를 사용하는지 여부 확인에 활용할 수 있습니다:

이전 IDE 장치(오래된 설정)에 대해 DMA를 활성화하려면, 다음 커널 기능을 활성화하십시오.

USB 호스트 컨트롤러
USB는 컴퓨터 외부 주변장치를 연결하는 목적으로 널리 적용한 버스 인터페이스입니다. USB가 성공한 이유는 표준화된 프로토콜이지만 USB host controller devices (HCDs)를 적은 다양성 범위 내에서 구현했기 때문입니다. USB 형식은 주로 4가지가 있습니다:


 * 1)   는 통합 호스트 컨트롤러 인터페이스입니다. USB 1.1을 지원하며 보통 VIA 또는 인텔 칩셋의 마더보드에서 찾을 수 있습니다.
 * 2)   는 공개 호스트 컨트롤러 인터페이스입니다. USB 1.1을 지원하며 보통 Nvidia 또는 SiS 칩셋의 마더보드에서 찾을 수 있습니다.
 * 3)   는 확장 호스트 컨트롤러 인터페이스입니다. USB 2.0을 지원하며 보통 USB 2.0을 지원하는 어떤 컴퓨터에서든 찾을 수 있습니다.
 * 4)   는 확장 가능한 호스트 컨트롤러 인터페이스입니다. USB 3.0을 지원하며 USB 1.0, 1.1, 2.0, 3.0 그리고 그 이상의 속도와 호환됩니다. 이 기능은 USB 3.0을 지원하는 보드에서 사용할 수 있습니다.

대부분 시스템은 XHCI (USB 3.0) 와 EHCI (USB 2.0) 두가지 인터페이스 형식을 달고 나옵니다. USB 장치를 사용하려면 XHCI가 느린 USB 컨트롤러와 호환되므로 더이상 XHCI와 EHCI 둘 다 선택하지 않아도 됩니다. 사용자는 EHCI를 추가 안전책으로 활성화할 수 있습니다. USB 2.0 컨트롤러를 사용할 수 없을 경우 아무 문제 없습니다.

시스템에 나타난 각 USB HCD 형식에 따른 관련 옵션을 선택하지 않으면 USB 포트가 '죽어있는' 경험을 할 지도 모릅니다. 이 경우 동작하는 USB 장치를 연결했을 때, 어떤식으로는 동작하지 않거나 응답하지 않습니다.

깔끔하게 ( 꾸러미에 있는)lspci 꼼수를 쓰면 시스템에 어떤 HCD 장치가 있는지 비교적 쉽게 찾을 수 있습니다. 일치하는 SATA 컨트롤러는 무시하고, 이 시스템에서 ECHI와 XHCI 지원 드라이버가 필요하다는 점을 쉽게 발견할 수 있습니다.

시스템에 나타나는 HCD를 선택하십시오. 보통 나타나는 모든 세가지 옵션이 최대 지원입니다만, 올바른 옵션인지 확실하지 않다면:

리눅스 커널 3.12.13 이후, USB 컨트롤러가 OHCI이고 USB 키보드 및 마우스를 사용하는 경우 OHCI support for PCI-bus USB controllers 를 활성화합니다.

다중 프로세서, Hyper-Threading 및 다중 코어 시스템
대부분 컴퓨터 시스템은 다중 프로세서 기반이지만, 항상 직접적으로 명백하게 다중 프로세서 방식으로 동작하는건 아닙니다.


 * 수많은 Intel CPU가 hyper-threading 기술을 지원합니다. 이 기술은 단일 CPU가 두개의 논리 프로세서(코어)처럼 보이도록합니다.
 * 대부분의 Intel/AMD CPU는 실제로 하나의 칩 패키지에 여러 물리 프로세서를 넣어, 이 프로세서를 다중 코어 프로세서라고 합니다.
 * 일부 고성능(high-end) 컴퓨터 시스템은 실제로 특별한 마더보드에 여러 물리 프로세서를 장착하여 단일 프로세서 시스템의 성능을 훨씬 뛰어넘는 성능을 발휘합니다. 시스템 사용자는 아마도 이런 시스템을 지니고 있다면 결코 싼 시스템이 아니라는걸 알 지도 모릅니다.

이 모든 경우, 적당한 커널 옵션을 선택하여 이 설정으로부터 최상의 성능을 끌어내야 합니다:

다음 옵션은 전원 관리 기능을 활성화 할 뿐만 아니라 시스템에 붙는 모든 CPU의 요구사항이기도 합니다:

x86 상위 메모리 영역 지원
x86 아키텍처의 32비트 주소 공간 제한 때문에 기본 설정을 지닌 커널은 램 용량을 896MB 까지만 지원할 수 있습니다. 시스템에 더 많은 용량의 메모리가 있다면, 상위 메모리 지원을 활성화하기 전에는 앞의 896MB 부분만 보입니다.

상위 메모리 영역 지원은 이제 기본적으로 비활성화 상태인데, 소규모 시스템의 과부하를 유발하기 때문입니다. 이 문제에 신경 쓰시지 마십시오. 더 많은 가용 메모리로 인한 성능 증가에 비하면 과부하는 별로 중요하지 않습니다.

4GB를 넘는 RAM을 보유하고 있지 않다면 4GB 옵션을 선택하십시오:

압축 커널 모듈
커널 버전 3.18.x(이상) 부터 커널 모듈 압축이 가능합니다. gzip과 xz 압축 방식을 활용할 수 있습니다. 압축 모듈로 커널을 컴파일 하기 전에 적당한 USE 플래그를 붙여 를 이머지하는 것이 중요합니다.

를 다시 이머지하십시오:

모듈 압축을 활성화하고 알맞은 압축 방식을 선택하십시오:

보통 에서 를 실행합니다. 에 적당한 USE 플래그를 설정하지 않았을 때(위 단계에서 참고) 처음 실행하면, 의존성 목록이 비어있을 것입니다. 때문에, 시스템에서는 압축한 상태로 빌드한 어떤 모듈이든 불러올 수 없습니다.

kmod를 다시 컴파일 하고 나면, 이 문제를 해결하기 위해 depmod를 다시 실행하십시오:

도입부
커널 설정 방법을 읽을 때, 종종 설정 항목은 로 나타납니다. 이 간편 표기 방식은 내부적으로 활용하는 커널 설정이며, 커널 설정 파일( 또는 자동으로 만든 )에서 찾아볼 수 있습니다. 물론, 간편 표기 방식이 커널 설정에 있어 실제 위치로 변환하는데 있어 썩 좋은 방식은 아닙니다. 도구는 이 문제를 풀어냅니다.

CONFIG_FOO를 실제 설정 위치로 변환하기
기능을 활성화해야 한다 합시다. 커널 설정 메뉴를 실행하고 키를 누르십시오. 검색 상자를 엽니다. 이 검색 상자에 를 입력하십시오.

다음은 이 검색 결과의 출력 내용입니다:

이 출력 결과는 수많은 정보를 보여줍니다.

이 정보를 통해 어떤  요구사항이든 해석이 쉬울 수 있습니다. 간단히 말해, 사용자는:


 * 1) Depends on 항목에 설명한 설정을 활성화해야 하고
 * 2) Location: 위치를 탐색하며
 * 3) Prompt: 항목에서 참고하는 값을 바꿔야합니다

기타 커널 설정 문서
지금까지는 일반적인 개념과 커널 설정에 대한 개별적인 문제에 대해서만 다루었습니다. 더 자세한 내용은 사용자의 이야기거리로 남겨둡니다. 그러나 젠투 문서 모음의 나머지 부분에서는 다루기 쉬운 주제에 대해 특별히 세부적인 내용을 제공합니다.

어떤 문서는 커널의 개별 설정 영역에 도움이 될 수도 있습니다. 이 경고는 앞서 언급했지만 기억해두십시오: 커널 설정을 처음 진행하는 사용자는 커널을 설정하려할 때 성급해서는 안됩니다. 기본적인 시스템을 띄워 시작하고, 동작하며 오디오, 인쇄 등의 기능 지원은 언제든 나중에 추가할 수 있습니다.

Getting the basics of a kernel operational will help users in later configuration steps because the user will know what is breaking their system and what is not. It is always wise to save the base (working) kernel configuration in a folder other than the kernel's sources folder before attempting to add new features or hardware.


 * The ALSA article details the configuration options required for sound card support. Note that ALSA is an exception to the suggested scheme of not building things as modules: ALSA is actually much easier to configure when the components are modular.


 * The Bluetooth article details the options needed in order to use Bluetooth devices.


 * The IPv6 router guide describes how to configure the kernel for routing using the next generation network addressing scheme.


 * If the closed-source nVidia graphics drivers will be used for improved 3D graphics performance, the nVidia Guide lists the options that should and should not be selected on such a system.


 * Amongst other things, the Power Management guide explains how to configure the kernel for CPU frequency scaling, and for suspend and hibernate functionality.


 * If running a PowerPC system, the PPC FAQ has a few sections about PPC kernel configuration.


 * The Printing guide lists the kernel options needed to support printing in Linux.


 * The USB Guide details the configuration settings required to use common USB devices such as keyboards, mice, storage devices, and USB printers.

바뀐 설정 적용 안됨
설정을 바꿀 때 사용자에게 일어나는 흔한 일이지만, 새로 설정한 커널을 실제로 부팅하는 과정에서 벌인 사소한 실수일 뿐입니다. 다시 설정한 커널이 아닌 커널 이미지로 다시 부팅했고 어떤 문제이든지 간에 풀려던 문제가 아직도 나타나고 있음을 찾고 있으며, 때문에 바꾸어놓은 설정이 문제를 해결하지 않았다고 볼 수 있습니다.

커널 컴파일 및 설치 과정은 이 문서의 범위를 벗어납니다. 일반적인 안내 내용을 보시려면 커널 업그레이드 안내서를 보십시오. 간단하게 말씀드리자면, 수정한 커널은 1&#41; 설정, 2&#41; 컴파일, 3&#41; (마운트 하지 않았다면) 마운트, 4&#41; 에 새 커널 이미지 복사, 5&#41; 새 커널을 참조하도록 부트로더 확인, 6&#41; 재부팅, 순서를 따릅니다. 중간에 빠진 절차가 있다면, 바뀐 결과대로 동작하지 않습니다.

하드디스크에서 새로 컴파일한 커널과 일치하는지 확인할 수 있습니다. 커널 컴파일한 날짜와 시각을 확인하면 됩니다. 시스템 아키텍처를 x86이라 하고 커널 소스 코드가 에 있다면 다음 명령을 사용하여 확인할 수 있습니다:

위 명령에서는 현재 부팅한 커널을 컴파일 한 날짜와 시각을 보여줍니다.

위 명령은 하드 디스크의 커널 이미지를 마지막으로 컴파일한 날짜와 시각을 보여줍니다.

위 명령에서 타임스탬프가 2분 이상 차이나면 커널 설치에 문제가 있어 새로 수정한 커널 이미지로 부팅하지 않았음을 나타냅니다.

모듈을 자동으로 불러오지 않음
이 문서 앞에서 언급했듯이 커널 설정 시스템에서는 커널 구성 요소를 빌드시 포함(Y)이 아닌 모듈(M)로 설정했을 때, 상당한 양의 동작상 변화를 숨깁니다. 이 문제에 수많은 사용자들이 낚일 수 있기 때문에 다시 말씀드리는게 좋을거라 보고 있습니다.

커널에 포함하여 빌드하도록 구성 요소를 선택하면, 소스 코드를 커널 이미지(bzImage)에 넣어 빌드합니다. 커널에서 해당 구성 요소를 필요로 한다면, 사용자의 개입 과정 없이 자동으로 초기화한 후 불러옵니다.

구성 요소를 모듈로 선택하면, 코드는 커널 모듈 파일로 빌드하며, 파일 시스템에 설치합니다. 보통, 커널이 해당 구성 요소를 사용해야 한다면 찾을 수 없습니다. 일부 예외적으로는, 실제 모듈을 불러오려고도 하지 않습니다. 이 작업은 사용자가 처리해야합니다.

만약 네트워크 카드를 모듈로 빌드하였고, 네트워크에 접근할 수 없는 문제를 발견했다면 아마도 모듈을 불러오지 않았기 때문일지도 모릅니다. 직접 모듈을 불러오거나 시스템에서 부팅 시간에 자동으로 모듈을 불러오도록 설정해야합니다.

사용자가 다른 방식을 취해야 할 이유가 있지 않는 한, 해당 구성 요소를 커널에 넣어 빌드하여 커널에서 자체적으로 일부 설정을 알아서 설정할 수 있게 하면 해결할 수 있습니다.

추가 참조

 * genkernel - 커널 및 initramfs 빌드 과정을 자동화할 때 쓰는 도구입니다.