제가 새 기계에서 리눅스 커널 빌드 환경을 셋업하고 실제 빌드, 설치하는 과정을 정리해 봅니다. 글 작성 과정에서 실제 커맨드를 수행한 환경은 Ubuntu 16.04.3 Server OS 를 설치한 x86_64 가상머신입니다.
Install Dependent Packages $ sudo apt install build-essential libncurses5-dev libssl-dev bc bison flex \ libelf-dev 커널을 빌드하려면 컴파일러와 라이브러리 등이 필요하겠죠. 위 커맨드는 우분투에서 커널 빌드에 필요한 패키지들을 깔아줍니다. 커널 트리의 Documentation/process/changes.rst 에도 커널 빌드에 필요한 패키지들이 나열되어 있으므로, 다른 환경이라면 이를 참고해 필요한 패키지를 설치합시다.
리눅스 커널의 개발은 커뮤니티 주도입니다. 개발의 한 부분인 테스트 역시 커뮤니티 주도적입니다. 여러 개인 또는 단체가 커널을 각자의 방식으로 테스트 하고 그 결과를 공유합니다. 인텔에서는 0-day 서비스[1] 라는 서비스를 자체적으로 돌리는데, 이 서비스는 최신 리눅스 커널을 가져다가 빌드하고 다양한 기능 / 성능 테스트를 돌리고 그 결과 발견된 regression 을 LKML 에 메일로 보내주는 일을 합니다. 말하자면 Continuous Integration (CI) 이죠.
Linux Kernel Performance (LKP) Tests[2] 는 0-day 서비스에서 기능 / 성능 테스트를 수행하는데 사용되는 도구입니다.
토발즈는 좋아하지 않지만, 리눅스 커널 프로그래밍에도 디버거를 사용할 수 있습니다. 저도 디버거 사용을 좋아하지는 않는 편이지만, 경우에 따라선 디버거를 사용하는게 좋을 때도 있고 취향은 존중되어야죠. ;)
커널 디버깅 방법은 여러가지가 있는데, 그 중 하나는 QEMU 등을 이용한 리눅스 가상 머신을 띄워 두고, 호스트 머신에서 해당 가상 머신의 리눅스 커널을 디버깅 하는 방법입니다. 이 글에선 이렇게 디버깅 하는 방법을 간단히 정리해 봅니다.
테스트 환경 글 작성 과정에서 테스트에 사용한 주요 소프트웨어들과 버전은 다음과 같습니다.
최근 커널은 stakc dump 에서 콜 트레이스(Call Trace) 에 각 코드의 메모리 어드레스를 찍어주지 않습니다. 이에 대해 포스팅을 해봅니다.
Call Trace 커널은 문제가 발생하거나 하면 문제의 원인을 찾을 수 있는 다양한 정보를 담고 있는 stack dump 를 로그로 뿌려 줍니다. 문제의 원인을 찾는데 매우 소중한 정보입니다. 그 정보 중에서도 중요한 것 중 하나가 콜 트레이스로, 이 문제의 순간에 오기까지 어느 함수의 어느 지점에서 어느 함수를 호출해서 여기까지 왔는가를 담는 정보입니다.
리눅스 커널은 오픈 소스 소프트웨어이므로 그 소스코드가 공개되어 있어 누구나 인터넷을 통해 쉽게 얻을 수 있습니다. 이 글에서는 리눅스 커널 소스코드를 받아올 수 있는 몇가지 방법을 설명합니다.
kernel.org 리눅스 커널 소스 코드를 받아오기 위한 기본적 공식 사이트는 [kernel.org] (https://www.kernel.org) 라 할 수 있겠는데, 이 사이트에는 소스 코드를 포함해 리눅스 커널을 위한 다양한 리소스가 정리되어 있습니다. 이 사이트에 웹브라우저를 통해 들어가보면 첫페이지에서부터 가장 최근에 릴리즈된 버전의 소스코드, 가장 최근의 안정화된 버전의 소스코드 등을 tar.