이 저장소에서 주요 커미터 별 그리고 linux kernel 안의 프로젝트 별로 저장소가 구분되어 있습니다.
우리가 contribution 할 프로젝트 'perf'는 커널 소스 안의 tools/perf 에 존재하는 프로젝트입니다. 이 프로젝트의 maintainer 는 'Arnaldo Carvalho de Melo' 이고, perf 툴의 모든 수정사항은 이 사람의 저장소에 가장 먼저 반영됩니다.
따라서, 우리는 'Arnaldo Carvalho de Melo'의 저장소를 clone 받아서 작업을 진행해야합니다.
아래 명령어로 저장소를 clone 받고, perf/core 브랜치를 checkout 합니다.
mkdir ~/work
cd work
git clone git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
git checkout perf/core
의존 라이브러리 설치
perf 를 컴파일하는데 필요한 라이브러리들이 있습니다. 아래 명령어를 실행하여 라이브러리를 설치합니다.
⚠️ debian 계열의 linux 를 기준의 명령어입니다. 다른 배포판의 경우 배포판에서 제공하는 패키지 설치 툴을 이용해서 라이브러리를 설치해주시기 바랍니다.
의존 라이브러리까지 설치를 완료하였으면, 컴파일이 제대로 되는지 확인해보아야합니다. 위에서 clone 받은 저장소 폴더에서 tools/perf 로 이동하여 컴파일을 진행합니다.
cd ~/work/linux/tools/perf
make
컴파일에 성공하면 맨 마지막에 아래와 같은 로그가 남고, toos/perf 디렉토리에 perf 실행파일이 생성됩니다.
CC util/pmu.o
CC util/pmu-flex.o
LD util/libperf-in.o
LD libperf-in.o
AR libperf.a
LINK perf
LINK libperf-gtk.so
2. 개발 시작하기
어떤 것부터 시작하는 것이 좋은가?
perf 를 이전부터 써 왔고, 평소에 불편한 점이 있었다면 그것을 개선하거나 버그를 고치는 작업을 먼저 진행할 수 있습니다. 하지만 처음 perf 를 접하는 사람에게는 어떤 것부터 접근해야할 지 막막합니다. 아래 목록은 처음 perf 를 접하고, contribution 을 하고 싶은 사람들에게 추천하는 첫 작업들 입니다.
Documentation/tips.txt 에 tip 추가하기
코드 리펙토링
perf 실행 결과화면 개선
ctags 로 코드 분석 환경 만들기
코드를 분석하다보면 함수들을 navigation 하면서 분석해야합니다. 우리가 일반적으로 많이 쓰는 IDE에서는 자체적으로 코드를 분석하여 손 쉽게 함수들의 정의로 이동하고 다시 되돌아오는 기능을 제공하지만, 터미널 환경의 에디터인 vim 에서는 그 기능을 제공하고 있지 않습니다.
따라서 ctags 라는 툴을 이용해서 vim 에서도 함수/변수 등의 정의 부분으로 빠르게 이동하고 되돌아오도록 환경을 구축해야합니다.
먼저 ctags 를 설치합니다.
sudo apt-get install ctags
그리고, 코드가 위치한 디렉토리로 이동하여 아래 ctags 를 실행하여 코드들을 분석합니다.
cd ~/work/linux
ctags -R
ctags 가 코드 분석을 끝내면 ~/work/linux 에 tags 라는 파일이 생성됩니다. 그리고 vim 에서 이용할 수 있도록 ~/.vimrc 파일을 아래와 같이 수정해줍니다.
set tags=~/work/linux/tags
자 그럼, 이제 모든 준비가 다 끝났습니다. vim 에서 소스코드를 열고 아래 단축키로 함수/변수 등의 정의부분으로 이동하거나 되돌아오기를 할 수 있습니다.
ctrl + ] : 정의 부분으로 가기
ctrl + t : 되돌아오기
코드의 탄생과정 추적하기
코드를 분석하다보면 내가 보고 있는 이 함수 혹은 이 코드가 언제 누구한테서 어떤 내용으로 생겨났는지 궁금해집니다. git 은 코드의 변경 내용을 다 기록하고 있기 때문에, git을 이용하면 손 쉽게 코드의 과거를 탐색할 수 있습니다.
예를 들어 tools/perf/util/color.c 파일을 보고 있는데 아래 함수가 어떻게 생겨났는지 알아보고 싶다고 가정해보겠습니다.
tools/perf/util/color.c
const char *get_percent_color(double percent)
{
const char *color = PERF_COLOR_NORMAL;
/*
* We color high-overhead entries in red, mid-overhead
* entries in green - and keep the low overhead places
* normal:
*/
if (fabs(percent) >= MIN_RED)
color = PERF_COLOR_RED;
else {
if (fabs(percent) > MIN_GREEN)
color = PERF_COLOR_GREEN;
}
return color;
}
git blame 명령어를 통해서 각 line 별로 누가 언제 마지막으로 수정했는지 확인해볼 수 있습니다.
git blame tools/perf/util/color.c
그러면 아래와 같이 commit-hash, 소스코드, 수정한 사람, 일시, 내용 순으로 blame 결과가 나오게 됩니다.
아래 내용을 보면 get_percent_color 라는 함수는 Frederic Weisbecker 라는 사람에 의해 만들어졌고, commit hash 1e11fd82d 에서 생성된 것을 알 수 있습니다.
git blame 으로 함수가 최초로 만들어진 시점을 보려면 { 가 생성된 날짜를 보면 됩니다. 그 이유는 함수명 부분은 함수가 만들어진 이 후 누군가에 의해 인자가 변경될 수 있지만 { 는 변경될 일이 없기 때문입니다.
blame 으로 원하는 코드의 내용이 언제 만들어졌는지 확인이 되면, 가장 처음에 나오는 commit hash 를 이용해서 상세한 commit 메세지와 동시에 어떤 파일들이 수정되었는지 알 수 있습니다.
commit hash 는 commit 에 대한 고유 값이며 특정 commit 을 나타내는 값 입니다.
우리가 살펴볼 commit hash 는 1e11fd82d 이고 아래 명령어로 해당 commit 내용을 확인할 수 있습니다.
git show 1e11fd82d
그럼 아래와 같이 commit 메세지와 함께 변경내용이 나오게 됩니다. 이것을 통해서 내가 알고자하는 코드 부분이 어떻게 생겨났는지 쉽게 파악할 수 있습니다.
commit 1e11fd82d247e4e48a1d6c49402214434538d3fd
Author: Frederic Weisbecker <fweisbec@gmail.com>
Date: Thu Jul 2 20:14:34 2009 +0200
perf_counter tools: Provide helper to print percents color
Among perf annotate, perf report and perf top, we can find the
common colored printing of percents according to the following
rules:
High overhead = > 5%, colored in red
Mid overhead = > 0.5%, colored in green
Low overhead = < 0.5%, default color
Factorize these multiple checks in a single function named
percent_color_fprintf() and also provide a get_percent_color()
for sites which print percentages and other things at the same
time.
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Anton Blanchard <anton@samba.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
LKML-Reference: <1246558475-10624-2-git-send-email-fweisbec@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index 08ea6c5..5f9eefe 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
패치 보내기
commit 메세지 작성하기
linux kernel 의 commit 메세지는 일반적인 commit 메세지에서 몇 가지 더 추가된 내용을 넣어주어야합니다.
commit 메세지의 간단한 형태는 다음과 같습니다.
perf 기능: 1줄의 간단한 수정 내용
자세한 수정 내용
Signed-off-by: 본인이름 <본인 이메일>
Cc: maintainer 이름 <maintainer 이메일>
일반적인 commit 메세지와 다른 점은 바로, Signed-off-by 로 나의 정보를 적어주고 Cc 에 maintainer 들의 정보를 달아준다는 점 입니다.
Signed-off-by 는 commit 시 -s 옵션을 통해 자동으로 넣어 줄 수 있고, Cc 는 수동으로 넣어주셔야 합니다.
# -s 옵션으로 Signed-off-by 를 넣어줍니다. 여기에 들어가는 내용은 ~/.gitconfig 에 있는 계정 정보가 들어갑니다다
#[user]
# email = nexusz99@gmail.com
# name = SeongSoo Cho
git commit -s
# 아래 maintainer 정보를 Signed-off-by 밑에 넣어줍니다.
Cc: David Ahern <dsahern@gmail.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jiri Olsa <jolsa@kernel.org>
patch 파일 만들기
이메일에 첨부할 패치 파일을 만들어야합니다. 아래 명령어를 이용하면 자동으로 0001-커밋내용.patch 라는 이름으로 패치파일이 만들어집니다.
git format-patch -1
패치파일을 열어보면 다음과 같은 내용이 들어갑니다.
From 3605345dd3c6c6c33c1739efe4de05641674fb31 Mon Sep 17 00:00:00 2001
From: SeongSoo Cho <nexusz99@gmail.com>
Date: Fri, 30 Sep 2016 03:51:37 +0900
Subject: [PATCH] perf diff: Introduce the new rules of colored printing of
delta.
As you know, there are the common colored printing of percents so overhead(%) can be c$
But Delta means difference percents from percents of overhead between two files e.g. p$
Although the rule is for overhead(%), Delta value also follow the same rule.
So, I think that it would be better to use the new colored rule for the Delta as below.
Increament: background colored in red (e.g. +0.50%)
Decrement: colored in blue (e.g. -5.50%)
Same: default color (e.g. +0.00%)
Instead of percent_color_snprintf() function, use new delta_color_snprintf() function.
Signed-off-by: SeongSoo Cho <nexusz99@gmail.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Taeung Song <taeung@kosslab.kr>
---
tools/perf/builtin-diff.c | 2 +-
tools/perf/util/color.c | 21 +++++++++++++++++++++
tools/perf/util/color.h | 1 +
3 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 9ff0db4..228bad1 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
....
메일링 리스트에 보내기
패치파일까지 만들어졌으면 linux kernel 메일링 리스트에 패치를 보내야합니다. 패치를 보내는 것도 git 을 이용합니다. 아래 명령어를 이용해서 send-email 을 설치합니다.
1. 개발 환경 구축
linux kernel 코드 다운로드
linux kernel 코드는 https://git.kernel.org git 저장소 에서 관리되고 있습니다.
이 저장소에서 주요 커미터 별 그리고 linux kernel 안의 프로젝트 별로 저장소가 구분되어 있습니다.
우리가 contribution 할 프로젝트 'perf'는 커널 소스 안의 tools/perf 에 존재하는 프로젝트입니다. 이 프로젝트의 maintainer 는 'Arnaldo Carvalho de Melo' 이고, perf 툴의 모든 수정사항은 이 사람의 저장소에 가장 먼저 반영됩니다.
따라서, 우리는 'Arnaldo Carvalho de Melo'의 저장소를 clone 받아서 작업을 진행해야합니다.
아래 명령어로 저장소를 clone 받고, perf/core 브랜치를 checkout 합니다.
의존 라이브러리 설치
perf 를 컴파일하는데 필요한 라이브러리들이 있습니다. 아래 명령어를 실행하여 라이브러리를 설치합니다.
⚠️ debian 계열의 linux 를 기준의 명령어입니다. 다른 배포판의 경우 배포판에서 제공하는 패키지 설치 툴을 이용해서 라이브러리를 설치해주시기 바랍니다.
컴파일 해보기
의존 라이브러리까지 설치를 완료하였으면, 컴파일이 제대로 되는지 확인해보아야합니다. 위에서 clone 받은 저장소 폴더에서 tools/perf 로 이동하여 컴파일을 진행합니다.
컴파일에 성공하면 맨 마지막에 아래와 같은 로그가 남고, toos/perf 디렉토리에 perf 실행파일이 생성됩니다.
2. 개발 시작하기
어떤 것부터 시작하는 것이 좋은가?
perf 를 이전부터 써 왔고, 평소에 불편한 점이 있었다면 그것을 개선하거나 버그를 고치는 작업을 먼저 진행할 수 있습니다. 하지만 처음 perf 를 접하는 사람에게는 어떤 것부터 접근해야할 지 막막합니다. 아래 목록은 처음 perf 를 접하고, contribution 을 하고 싶은 사람들에게 추천하는 첫 작업들 입니다.
ctags 로 코드 분석 환경 만들기
코드를 분석하다보면 함수들을 navigation 하면서 분석해야합니다. 우리가 일반적으로 많이 쓰는 IDE에서는 자체적으로 코드를 분석하여 손 쉽게 함수들의 정의로 이동하고 다시 되돌아오는 기능을 제공하지만, 터미널 환경의 에디터인 vim 에서는 그 기능을 제공하고 있지 않습니다.
따라서 ctags 라는 툴을 이용해서 vim 에서도 함수/변수 등의 정의 부분으로 빠르게 이동하고 되돌아오도록 환경을 구축해야합니다.
먼저 ctags 를 설치합니다.
그리고, 코드가 위치한 디렉토리로 이동하여 아래 ctags 를 실행하여 코드들을 분석합니다.
ctags 가 코드 분석을 끝내면 ~/work/linux 에 tags 라는 파일이 생성됩니다. 그리고 vim 에서 이용할 수 있도록 ~/.vimrc 파일을 아래와 같이 수정해줍니다.
자 그럼, 이제 모든 준비가 다 끝났습니다. vim 에서 소스코드를 열고 아래 단축키로 함수/변수 등의 정의부분으로 이동하거나 되돌아오기를 할 수 있습니다.
코드의 탄생과정 추적하기
코드를 분석하다보면 내가 보고 있는 이 함수 혹은 이 코드가 언제 누구한테서 어떤 내용으로 생겨났는지 궁금해집니다. git 은 코드의 변경 내용을 다 기록하고 있기 때문에, git을 이용하면 손 쉽게 코드의 과거를 탐색할 수 있습니다.
예를 들어 tools/perf/util/color.c 파일을 보고 있는데 아래 함수가 어떻게 생겨났는지 알아보고 싶다고 가정해보겠습니다.
tools/perf/util/color.c
git blame 명령어를 통해서 각 line 별로 누가 언제 마지막으로 수정했는지 확인해볼 수 있습니다.
그러면 아래와 같이 commit-hash, 소스코드, 수정한 사람, 일시, 내용 순으로 blame 결과가 나오게 됩니다.
아래 내용을 보면 get_percent_color 라는 함수는 Frederic Weisbecker 라는 사람에 의해 만들어졌고, commit hash 1e11fd82d 에서 생성된 것을 알 수 있습니다.
git blame 으로 함수가 최초로 만들어진 시점을 보려면 { 가 생성된 날짜를 보면 됩니다. 그 이유는 함수명 부분은 함수가 만들어진 이 후 누군가에 의해 인자가 변경될 수 있지만 { 는 변경될 일이 없기 때문입니다.
blame 으로 원하는 코드의 내용이 언제 만들어졌는지 확인이 되면, 가장 처음에 나오는 commit hash 를 이용해서 상세한 commit 메세지와 동시에 어떤 파일들이 수정되었는지 알 수 있습니다.
commit hash 는 commit 에 대한 고유 값이며 특정 commit 을 나타내는 값 입니다.
우리가 살펴볼 commit hash 는 1e11fd82d 이고 아래 명령어로 해당 commit 내용을 확인할 수 있습니다.
그럼 아래와 같이 commit 메세지와 함께 변경내용이 나오게 됩니다. 이것을 통해서 내가 알고자하는 코드 부분이 어떻게 생겨났는지 쉽게 파악할 수 있습니다.
패치 보내기
commit 메세지 작성하기
linux kernel 의 commit 메세지는 일반적인 commit 메세지에서 몇 가지 더 추가된 내용을 넣어주어야합니다.
commit 메세지의 간단한 형태는 다음과 같습니다.
일반적인 commit 메세지와 다른 점은 바로, Signed-off-by 로 나의 정보를 적어주고 Cc 에 maintainer 들의 정보를 달아준다는 점 입니다.
Signed-off-by 는 commit 시 -s 옵션을 통해 자동으로 넣어 줄 수 있고, Cc 는 수동으로 넣어주셔야 합니다.
patch 파일 만들기
이메일에 첨부할 패치 파일을 만들어야합니다. 아래 명령어를 이용하면 자동으로 0001-커밋내용.patch 라는 이름으로 패치파일이 만들어집니다.
패치파일을 열어보면 다음과 같은 내용이 들어갑니다.
메일링 리스트에 보내기
패치파일까지 만들어졌으면 linux kernel 메일링 리스트에 패치를 보내야합니다. 패치를 보내는 것도 git 을 이용합니다. 아래 명령어를 이용해서 send-email 을 설치합니다.
그리고 ~/.gitconfig 에 자신의 이메일 계정 정보를 입력합니다.
그 다음 git 의 send-email 명령어를 입력하여 perf 의 maintainer 인 'Arnaldo Carvalho de Melo' 에게 패치가 담긴 이메일을 보내고, 추가적으로 몇몇 maintainer 들에게 CC를 걸어서 내용을 공유해줍니다.
메일이 성공적으로 보내졌다면, 자신의 메일의 보낸메일함에서 제대로 보내졌는지 확인하고 http://lkml.org/ 에서도 보이는지 확인합니다.
http://lkml.org/ 에서 보인다면 패치가 잘 보내진 것 입니다. 이제 결과가 반영되거나, 피드백 메일만 기다리면 됩니다.