제가 새 기계에서 리눅스 커널 빌드 환경을 셋업하고 실제 빌드, 설치하는 과정을 정리해 봅니다. 글 작성 과정에서 실제 커맨드를 수행한 환경은 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 서비스에서 기능 / 성능 테스트를 수행하는데 사용되는 도구입니다.
You can use classical debugger for your Linux kernel programming, though Torvalds doesn’t like it. I also do not prefer such use of debuggers, but admit that sometimes debuggers are quite useful. ;)
There are several ways to debug Linux kernel, but one of above is to set up a Linux virtual machine using QEMU and debugging the Linux kernel of the virtual machine from the host machine. This post summarises how to debug the Linux kernel in this way.
최근 커널은 stakc dump 에서 콜 트레이스(Call Trace) 에 각 코드의 메모리 어드레스를 찍어주지 않습니다. 이에 대해 포스팅을 해봅니다.
Call Trace 커널은 문제가 발생하거나 하면 문제의 원인을 찾을 수 있는 다양한 정보를 담고 있는 stack dump 를 로그로 뿌려 줍니다. 문제의 원인을 찾는데 매우 소중한 정보입니다. 그 정보 중에서도 중요한 것 중 하나가 콜 트레이스로, 이 문제의 순간에 오기까지 어느 함수의 어느 지점에서 어느 함수를 호출해서 여기까지 왔는가를 담는 정보입니다.
리눅스 커널은 오픈 소스 소프트웨어이므로 그 소스코드가 공개되어 있어 누구나 인터넷을 통해 쉽게 얻을 수 있습니다. 이 글에서는 리눅스 커널 소스코드를 받아올 수 있는 몇가지 방법을 설명합니다.
kernel.org 리눅스 커널 소스 코드를 받아오기 위한 기본적 공식 사이트는 [kernel.org] (https://www.kernel.org) 라 할 수 있겠는데, 이 사이트에는 소스 코드를 포함해 리눅스 커널을 위한 다양한 리소스가 정리되어 있습니다. 이 사이트에 웹브라우저를 통해 들어가보면 첫페이지에서부터 가장 최근에 릴리즈된 버전의 소스코드, 가장 최근의 안정화된 버전의 소스코드 등을 tar.