2012년 10월 16일 화요일

리눅스에 패치 업로드 하기


리눅스에 패치 업로드 하기
Author : SeongJae Park <sj38.park@gmail.com>


이 저작물은 크리에이티브 커먼즈 [저작자표시-동일조건변경허락 2.0 대한민국 라이선스]에 따라 이용할 수 있습니다.


지난 10월 11일~12일, 서울시 JW marriott 호텔에서 Korea Linux Forum 2012 행사가 있었습니다.
여러가지 좋은 발표와 강의, 대담등이 있었습니다만, Write and submit your first Linux kernel patch 라는 제목의, 리눅스 staging 트리를 관리하는 Greg Kroah-Hartman 의 발표는 개인적으로 가장 인상깊은 발표 중 하나였습니다.
발표 능력도 인상깊었고, 발표 내용 또한 상당히 유익했기에, 한국어로 해당 발표의 내용을 한글 문서로 정리해 보는 것은 리눅스에 컨트리뷰션을 하고자 하는 많은 한국 개발자에게 도움이 될 수 있지 않을까 싶어 문서로 정리해 봅니다.
Greg Kroah-Hartman 의 발표 문서는 https://github.com/gregkh/kernel-tutorial에서 얻을 수 있으며, 해당 발표 동영상은 http://www.youtube.com/watch?v=XXix80GCvpo 에서 확인 할 수 있습니다.
동영상은 안타깝게도 오디오 상의 문제로 상태가 좋지만은 못합니다. 같은 주제로 Greg이 한 몇년 전의 다른 발표 동영상들도 Youtube에 있으니, 그걸 보는 것도 좋을 것 같습니다.
FOSDEM 2010 에서 있었던 같은 주제의 발표 동영상을 추천합니다.
2년 전 발표라 조금 다른 부분도 있지만, 전체적 내용은 같더군요.
http://www.youtube.com/watch?v=LLBrBBImJt4


엄청나게 많은 분들이 리눅스를 사용하고 있고 또한 굉장히 많은 분들이 리눅스를 개발자로써 사용하고 있습니다. 이 과정에서 리눅스의 많은 문제점들을 마주하게 되고 수정하게 되지만, 이걸 upstream에 보내는 건 또한 쉬운 일이 아니지요.
치명적인 문제를 찾거나 엄청난 개선을 했고, 세상의 많은 이들에게 도움을 주기 위해 이를 upstream - 리누스 토발즈가 직접 관리하는 메인 소스코드 저장소 - 에 보내고자 하지만, reject 되는 경우가 많습니다. 하지만 대부분은 리눅스의 개발 프로세스, 패치를 보내는 과정과 주의할 점 등을 몰랐기 때문인 경우라고 합니다. 사실 그걸 모르니 패치를 보내지 못하는 경우도 많구요.

이 문서는 리눅스에서 발견한 문제를 수정하고 이 수정 내용을 어떻게 패치로 만들어서 upstream의 리눅스에 적용되도록 하는지 알아봅니다.
이를 위해, 가장 사소하지만 중요한, 코딩 스타일이 잘못된 파일들을 수정하고 이걸 패치로 만들어서 보내는 과정을 함께 진행해 보겠습니다.
전체 워크플로를 크게 정리하면 이렇습니다.

  1. 소스코드 받아오기(개발환경 구축)
  2. 문제점 발견
  3. 문제점 수정, 확인
  4. 패치 만들기
  5. 패치 보내기



소스 코드 받아오기

대부분의 오픈소스 개발방식을 사용하는 프로젝트가 그렇듯이, 리눅스 또한 다양한 트리와 브랜치를 이용해 개발되고 있습니다.
따라서, 올바른 소스 트리에서 코드를 받아오고, 올바른 소스 트리로 패치를 보내는 것이 필요한데요.
리눅스의 경우, 다음 버전에 머지되기를 기다리는 패치를 위해 linux-next 트리가 존재합니다. 아주 특수한 경우가 아니라면 모든 패치는 이 트리로 업로드 하는 것이 좋겠습니다.
먼저, 해당 트리의 코드를 가져와야겠죠. git clone을 쓰는 것도 하나의 방법이겠구요. 패치 하나만 만들어 보고 끝낼 게 아니라 이미 특정 트리의 소스코드를 clone해서 쓰고 있다면, remote로 linux-next를 추가하고 fetch 해서 쓰는 걸 권장합니다.

linux-next 트리의 저장소 주소는 다음과 같습니다.
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git


단순히
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git


으로 소스코드를 가져올 수 있구요,

앞서 설명했듯 이미 특정 트리를 clone해서 저장소를 만들어 두신 상태라면, 다음과 같은 명령으로 linux-next를 remote에 추가하고 소스코드를 가져와 작업 디렉토리를 구성할 수 있습니다.
$ git remote add linux-next git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
$ git fetch linux-next
$ git fetch --tags linux-next



그리고, 소스코드를 가져온 지 오래되었을 경우에는 다음과 같은 명령으로 업데이트를 해야겠죠.
$ git remote update

구글의 kernel.org 공식 미러
kernel.org 에서 소스코드를 받는 건 아무래도 조금 느린 면이 있는데요, 구글에서는 https://kernel.googlesource.com/ 에서 kernel.org 의 미러(mirror)를 제공하고 있으며, 이 서비스는 세계 각지의 구글 데이터 센터를 이용하기 때문에 상당히 빠른 속도를 보인다고 합니다. 해당 서비스에 대한 구글의 공지글은 다음 링크를 따라가면 볼 수 있습니다.
http://google-opensource.blogspot.kr/2012/04/worldwide-mirrors-of-gitkernelorg.html

여기를 이용할 경우, 위의 명령어들에서 linux-next 트리의 git 저장소 주소를 https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next
로 변경해 주시면 되겠습니다.
구글의 미러에 대한 정보는 이호민님(https://plus.google.com/u/0/118040095502884745897/about)께서 알려주셨습니다. 다시 한번 감사 말씀 드립니다 :)


문제점 찾기

일단 문제점이 있어야 수정을 하겠죠.
문제점은 직접 발견할 수도, 남들이 찾고 이야기한 걸 참고할 수도 있겠는데요. 다양한 방법이 있겠습니다. 메일링 리스트를 구독할 수도 있겠고, 이슈 트래킹 시스템을 이용할 수도 있겠죠.
아래는 커널 버그질라 페이지입니다. 최신 커널에 대한 내용으로 업데이트 되어 있지 않다고 합니다만, 잘 찾아보면 재미있는 버그를 찾을 수도 있을 겁니다.
https://bugzilla.kernel.org/query.cgi?format=advanced
그리고, 다음 링크를 따라가시면 메인 커널 메일링 리스트를 확인할 수 있습니다.
http://vger.kernel.org/vger-lists.html#linux-kernel

하지만, 처음 컨트리뷰션을 하려 마음 먹었을 때 하기 쉬운 실수 중 하나가, 처음부터 거대한 패치를 하려 하는 경우라고 합니다. 물론 여러분의 패치는 훌륭하고 그걸 upstream에 넣으면 세상을 위한 큰 도움이 되겠지만, 실제로 그 패치를 프로젝트에 머지해야할 메인터너(maintainer) 입장에선 그렇지많은 않다는 이야기죠. 대부분은 패치를 한두개만 올리고는 더이상 패치를 보내지 않는다고 합니다. 메인터너 입장에선 이를 감안할 때, 커다란 수정 내용의 패치를 함부로 머지하면, 해당 패치를 보냈던 사람이 더이상 해당 부분을 관리하지 않으면 그로 인한 문제도 크다는 거죠. 따라서, 메인터너와의 '신뢰'를 얻는 게 중요하다고 합니다.
따라서, 여기선 심각한 문제가 아니라 일단 간단하게 따라해 볼 수 있고, 그렇지만 중요한 문제점을 찾아가 보겠습니다.
코딩 스타일입니다.
코딩 스타일이 얼마나 사소해보이지만 심각한 문제인지에 대해선 따로 이야기 하지 않겠습니다 ;)

아시다시피 리눅스는 엄격한 코딩 스타일이 있지만, 여러가지 이유로 지켜지지 않는 파일들도 많다고 하며, 이런 것들을 수정해 주는 건 큰 도움이 될 수 있겠죠.
리눅스 소스코드에는 코딩 스타일을 검사해 주는 툴, checkpatch.pl 이 scripts/ 디렉토리 아래에 있습니다. 이걸 이용해 다음과 같은 명령으로 검사할 수 있습니다.
./scripts/checkpatch.pl [--terse] --file <검사할 파일 경로>


--terse 옵션은 검사 결과를 각각 한줄씩으로 나타내라는 옵션이구요. 옵션은 이외에도 많으며, 다음의 명령으로 사용법을 볼 수 있습니다.
./scripts/checkpatch.pl --help


예를 들어 drivers/staging/csr/csr_framework_ext_types.h 를 <검사할 파일 경로>에 넣으면, 다음과 같이 코딩 스타일을 어긴 내용을 알려줍니다.
drivers/staging/csr$ ../../../scripts/checkpatch.pl --terse --file csr_framework_ext_types.h
csr_framework_ext_types.h:5: ERROR: code indent should use tabs where possible
csr_framework_ext_types.h:6: ERROR: code indent should use tabs where possible
csr_framework_ext_types.h:8: ERROR: code indent should use tabs where possible
csr_framework_ext_types.h:9: ERROR: code indent should use tabs where possible
csr_framework_ext_types.h:28: ERROR: open brace '{' following struct go on the same line
csr_framework_ext_types.h:29: WARNING: please, no spaces at the start of a line
csr_framework_ext_types.h:30: WARNING: please, no spaces at the start of a line
csr_framework_ext_types.h:34: ERROR: open brace '{' following struct go on the same line
csr_framework_ext_types.h:36: WARNING: please, no spaces at the start of a line
csr_framework_ext_types.h:37: WARNING: please, no spaces at the start of a line
csr_framework_ext_types.h:40: WARNING: do not add new typedefs
csr_framework_ext_types.h:41: WARNING: do not add new typedefs
csr_framework_ext_types.h:42: WARNING: do not add new typedefs
csr_framework_ext_types.h:47: ERROR: open brace '{' following struct go on the same line
csr_framework_ext_types.h:48: WARNING: please, no spaces at the start of a line
csr_framework_ext_types.h:49: WARNING: please, no spaces at the start of a line
csr_framework_ext_types.h:50: WARNING: please, no spaces at the start of a line
csr_framework_ext_types.h:53: WARNING: do not add new typedefs
csr_framework_ext_types.h:54: WARNING: do not add new typedefs
csr_framework_ext_types.h:55: WARNING: do not add new typedefs
total: 7 errors, 13 warnings, 63 lines checked


7개의 error와 13개의 warning을 찾았습니다.
이 파일을 수정하고 패치를 만들어 보내 보겠습니다.
참고로, 이 파일은 제가 수정해서 이미 패치를 보냈으니, 만약 해당 패치가 머지된다면 이 문서를 보고 해당 파일에 같은 명령어를 실행할 경우 다른 결과가 나올 수도 있을 겁니다 ;)

여담이지만, Korea Linx Forum 2012의 'Write and submit your first Linux kernel patch' 세션의 경우, Greg Kroah-Hartman은 이와 같이 코딩 스타일을 수정해야 할 파일의 목록을 종이 조각에 인쇄해 와서, 사람들에게 이 종이 조각을 하나씩 나눠주더군요. 1주일 내로 수정해서 패치를 작성해 보내 보라고 말입니다 ;)

문제점 수정하기

문제점 수정은 각자 편한 방법으로 진행하면 되겠습니다. 여기선 코딩 스타일을 수정하면 되니, 저는 제게 익숙한 vim 편집기로 수정을 진행하겠구요.

토픽 브랜치(topic branch) 만들기

수정을 하기 전에 topic branch를 만드는 게 좋습니다. git 에서는 브랜칭의 비용이 굉장히 적기 때문에, 이렇게 작업하는 걸 선호하고, 리눅스 메인터너들도 이걸 선호할테니, 이 방법을 씁시다.
이제부터 git 사용이 나올텐데, git에 대한 자세한 내용을 알고 싶다면 다른 문서나 책을 보시는 게 좋겠습니다. Pro Git 라는 책(http://git-scm.com/book)을 개인적으로 추천합니다.
토픽 브랜치에 대해 더 알고 싶다면, http://www.kernel.org/pub/software/scm/git/docs/howto/separating-topic-branches.txt 등의 문서를 참고하세요.
다음의 명령으로 현재 브랜치들의 목록과 자신이 위치한 브랜치를 알 수 있습니다.
$ git branch
* master


그리고, 다음의 명령으로 패치를 만들 브랜치를 만들고, 바로 그리로 이동합니다.
$ git checkout -b fix_csr_codingstyle
M drivers/staging/csr/csr_framework_ext_types.h
Switched to a new branch 'fix_csr_codingstyle'


다시 브랜치 목록과 자신이 위치한 브랜치를 확인해 보면...
$ git branch
* fix_csr_codingstyle
 master


정상적으로 브랜치가 생성되고 해당 브랜치로 이동했습니다.
수정을 마치고 나서 checkpatch를 돌려보면...
drivers/staging/csr$ ../../../scripts/checkpatch.pl --terse --file csr_framework_ext_types.h
csr_framework_ext_types.h:38: WARNING: do not add new typedefs
csr_framework_ext_types.h:39: WARNING: do not add new typedefs
csr_framework_ext_types.h:40: WARNING: do not add new typedefs
csr_framework_ext_types.h:50: WARNING: do not add new typedefs
csr_framework_ext_types.h:51: WARNING: do not add new typedefs
csr_framework_ext_types.h:52: WARNING: do not add new typedefs
total: 0 errors, 6 warnings, 60 lines checked


대략 위와 같은 결과가 나왔군요. warning이 좀 남았지만, 일단 간단한 수정만으로 만족하겠습니다.

빌드해보기

이제 본격적으로 패치를 만들어보기 시작해야 할텐데요, 먼저 수정 내용은 제대로 되었다는 걸 확실히 해야겠죠.
빌드는 제대로 되는지, 증상은 제대로 수정되었는지 확인해 봅시다.
빌드는 다음의 명령처럼 해당 모듈만 빌드해 볼 수도 있겠지만, 전체 커널을 다시 빌딩해보고 실행해서 문제가 제대로 수정되었음을 확실히 해야겠죠.
make M=drivers/staging/csr


패치 만들기

이제, 패치를 만들어 보겠는데, 리눅스는 git로 관리되는 만큼, 너무나도 간단하고 쉽습니다.

git status

git status 명령은 현재 수정한 내용을 보여줍니다.
$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified:   drivers/staging/csr/csr_framework_ext_types.h
#
no changes added to commit (use "git add" and/or "git commit -a")


git add

다음 명령을 통해 수정한 파일을 commit할 것임을 알립니다.
$ git add drivers/staging/csr/csr_framework_ext_types.h


git commit

이제, commit합니다.
$ git commit


commit 메세지 작성할 에디터가 뜨겠죠.
commit 메세지 또한 중요한데요. 먼저 수정한 모듈과 수정한 내용을 짧게 제목으로 정리하고, 한줄을 그냥 띄운 후, 그 아래(세번째 줄)에 자세한 설명을 적어 줍니다.
git log 명령을 통해 남들은 어떻게 쓰는지 알 수 있겠구요.
아래는 제가 쓴 commit 메세지입니다.
   staging: csr: fix coding style
   
   Fix coding style of csr_framework_ext_types.h
   
   Signed-off-by: SeongJae Park <sj38.park@gmail.com>


마지막 줄에 Signed-off-by 라는 부분이 눈에 띌 텐데요, Signed-off-by는 개발자들이 해당 commit에 다는 증명서로, 다음과 같은 의미를 띕니다.
  1. 내가 이 수정 사항을 만들었다; 또는
  2. 기존 작업 내용과 잘 호환되는 라이센스 하에 이 수정 사항을 만들었다;
  3. 또는 앞의 두가지와 이 세번째 항목에 의해 내가 이 수정 사항을 받았으며, 내가 이에 대해 어떤 수정을 가하진 않았다.
  4. 이 commit은 public 하다.
이걸 쓰기 위해 별도의 툴을 쓰거나 할 필요는 없고, 그냥 키보드로 저렇게 타이핑 해 주시면 됩니다.

git format-patch

분산 버전 관리 시스템을 사용하지 않은 사람은 조금 헷갈릴 수도 있겠습니다. git과 같은 분산 버전 관리 시스템은 각 개발자가 사용하는 컴퓨터 파일 시스템 위에 독립된 저장소를 만드는 것이기 때문에, 앞서 행한 commit은 자신의 파일 시스템 위의 독립된 저장소에 commit한 것이지, 네트웍 상에 존재하는 메인 저장소로 commit 한 것이 아닙니다.
이제, 리눅스 메인터너들이 많이 쓰는 형식의 패치를 만들어 봅시다.
간단히, 다음의 git format-patch 명령으로 패치를 만들 수 있습니다.
$ git format-patch master..HEAD
0001-staging-csr-fix-coding-style.patch


소스코드를 땡겨온 후 아무 변경도 가하지 않은 master 브랜치와, 현재 HEAD가 가리키고 있는(우리가 위치해 있는), topic 브랜치 사이의 commit들을 이용해 패치 파일을 만들고, 생성한 패치 파일의 파일명을 보여 줍니다.
드디어 패치를 만들었습니다.
이제, 이 파일만 메인터너에게 보내면 됩니다.

패치 보내기

패치를 보낼 사람 찾기

먼저, 패치를 누구에게 보낼지 알아야겠죠. 기왕이면 착하고 똑똑한 메인터너에게 보내야겠지만, 수정한 부분을 관리하는 메인터너에게 보내야 할 것입니다.
수정한 파일의 메인터너를 찾는 툴도 리눅스 소스코드에 있습니다. 다음의 명령을 이용합니다.
$ ./scripts/get_maintainer.pl 0001-staging-csr-fix-coding-style.patch
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (supporter:STAGING SUBSYSTEM,commit_signer:3/4=75%)
devel@driverdev.osuosl.org (open list:STAGING SUBSYSTEM)
linux-kernel@vger.kernel.org (open list)


devel@driverdev.osuosl.org가 적당하겠군요.

git 메일 설정

git는 패치 파일을 메일로 쓰는 것도 도와줍니다.
하지만, 이를 위해선 다음 명령어로 git-email을 설치해야 합니다. 이미 설치하셨다면, 설치할 필요 없겠죠.
$ sudo apt-get install git-email


그리고, 메일 설정을 해주는데요. git가 메일을 보낼 수 있도록, smtp 서버 등을 설정 해야 합니다. gmail을 이용한다면 다음과 같이 설정하면 됩니다.
$ git config --global sendemail.smtpserver smtp.gmail.com
$ git config --global sendemail.smtpserverport 587
$ git config --global sendemail.smtpencryption tls
$ git config --global sendemail.smtpuser <본인의 이메일 주소>


이렇게 설정하면 git을 이용해 메일을 보낼 때 git이 gmail 패스워드를 입력하라고 프롬프트를 띄워주는데요.
만약 그것도 귀찮다면 다음과 같이 패스워드도 설정할 수 있습니다.
$ git config --global sendemail.smtppass your_password


하지만, 보안을 위해선 패스워드는 저장하지 않는 게 좋지 않겠나 싶습니다.

메일 보내기

이제, 다음의 명령을 이용해 메일을 보냅니다.
$ git send-email --to <보낼 곳 메일 주소>


몇가지 질문이 나오는데 잘 읽고 답하도록 하며, y/n 등의 선택지가 나오지 않는 건 그냥 엔터로 기본값을 사용하도록 설정합니다. 대부분 엔터/y로 귀결될 겁니다.

앞서 작성한 메일의 경우, 다음과 같은 명령으로 보낼 수 있겠습니다.
$ git send-email --to devel@driverdev.osuosl.org *.patch
0001-staging-csr-fix-coding-style.patch
Who should the emails appear to be from? [SeongJae Park <sj38.park@gmail.com>]
Emails will be sent from: SeongJae Park <sj38.park@gmail.com>
Message-ID to be used as In-Reply-To for the first email?
(mbox) Adding cc: SeongJae Park <sj38.park@gmail.com> from line 'From: SeongJae Park <sj38.park@gmail.com>'
(body) Adding cc: SeongJae Park <sj38.park@gmail.com> from line 'Signed-off-by: SeongJae Park <sj38.park@gmail.com>'

From: SeongJae Park <sj38.park@gmail.com>
To: devel@driverdev.osuosl.org
Cc: SeongJae Park <sj38.park@gmail.com>
Subject: [PATCH] staging: csr: fix coding style
Date: Tue, 16 Oct 2012 16:15:42 +0900
Message-Id: <1350371742-831-1-git-send-email-sj38.park@gmail.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

   The Cc list above has been expanded by additional
   addresses found in the patch commit message. By default
   send-email prompts before sending whenever this occurs.
   This behavior is controlled by the sendemail.confirm
   configuration setting.

   For additional information, run 'git send-email --help'.
   To retain the current behavior, but squelch this message,
   run 'git config --global sendemail.confirm auto'.

Send this email? ([y]es|[n]o|[q]uit|[a]ll): y
Password:
OK. Log says:
Server: smtp.gmail.com
MAIL FROM:<sj38.park@gmail.com>
RCPT TO:<devel@driverdev.osuosl.org>
RCPT TO:<sj38.park@gmail.com>
From: SeongJae Park <sj38.park@gmail.com>
To: devel@driverdev.osuosl.org
Cc: SeongJae Park <sj38.park@gmail.com>
Subject: [PATCH] staging: csr: fix coding style
Date: Tue, 16 Oct 2012 16:15:42 +0900
Message-Id: <1350371742-831-1-git-send-email-sj38.park@gmail.com>
X-Mailer: git-send-email 1.7.9.5
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Result: 250 2.0.0 OK 1350371762 y5sm10389071pav.36


기다리기

이제, 지루한 기다림의 시간입니다. 패치는 세계 각지에서 엄청난 양이 쏟아지므로, 메인터너들이 메일을 바로 보지는 못할 겁니다. 이 문서를 작성하며 보낸 패치에 대해서도 아직 어떤 답장이나 연락도 없습니다.
운이 좋으면 빠르게, 없다면 좀 천천히 연락이 올겁니다.
중요한 패치인데 답이 너무 느리다면 정중히 해당 메인터너에게 메일을 보내 보는 것도 좋은 방법입니다.


피드백 받고 보내기

메일을 보내면 생각보다 빨리 피드백을 받습니다. 오자가 섞인 패치를 실수로 보낸 적 있는데, 이틀만에 이를 지적당했고, 약 일주일만에 머지됐습니다!
문제가 있어 보이면 그에 대해 발견한 사람들이 바로바로 피드백을 줍니다.
이에 대해서는 적당히 정말 잘못됐다면 시인하고 새로운 패치를 만들어 보내고, 그쪽 문제제기가 잘못되었다면 오해가 있는 것 같다고 정중하게 잘 말합시다. 적당히 강경하고 적당히 인정하는 자세가 필요하겠죠. 분명한 건, 다들 훌륭한 커널을 만들려 노력하고 있다는 것 같습니다.


순수 문자로만 메일 보내기

한가지 유의할 점은, 리눅스 메일링 리스트로 gmail에서 답장을 그냥 보내면, 아래와 같은 전송 실패 메세지가 도착합니다.
Delivery to the following recipient failed permanently:

    linux-kernel@vger.kernel.org

Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550 5.7.1 Content-Policy reject msg: The message contains HTML subpart, therefore we consider it SPAM or Outlook Virus.  TEXT/PLAIN is accepted.! BF:<U 0.494653>; S1753440Ab2JPHiz (state 17).


본문에 html이 섞여 있다는 건데요. 이건 gmail의 메일 작성창에 Rich formatting이 기본으로 켜져 있어서입니다. 패치 보낼 땐 git send-email이 알아서 잘 해줬지만, gmail 기본 입력창은 Rich formatting이 켜져 있어서 내부적으로 html을 섞습니다.
gmail 입력창 바로 위의 Plain text 를 클릭해 plain text(html 등이 섞이지 않은 순수한 문자)로 메일 본문이 작성되도록 합시다.
쥐메일이 아니라도 비슷한 상황이 있을 수 있을 겁니다.


머지 완료 메세지

위의 과정을 잘 거치고 인내와 토론을 잘 했다면, 머지 되었음을 다음과 같은 이메일로 통보 받습니다.
This is a note to let you know that I've just added the patch titled

   staging: csr: csr_framework_ext_types.h: fix coding style

to my staging git tree which can be found at
   git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
in the staging-next branch.

The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)

The patch will also be merged in the next major kernel release
during the merge window.

If you have any questions about this process, please let me know.


X나 좋군요!?

참고자료


2012년 10월 13일 토요일

리눅스의 주역들을 만나다 - Korea Linux Forum 2012 후기 -

이번 10월 11일과 12일, Korea Linux Forum 2012 가 열렸습니다.
http://events.linuxfoundation.org/events/korea-linux-forum

Samsung과 Intel이 주된 스폰서로 참여했고, Linux Foundation 주최로 열린 행사였는데요.
Linux Developer 들이 대거 참여하셨고, Linux 의 아버지, Linus Torvalds 형님께서 참가하신다는 점에서 여러모로 사람들을 들뜨게 만들었죠.

당연하게도 매우 애타게 여기 참가하기 위해 이래저래 노력했고, 이런저런 우여곡절 끝에 저도 참가할 수 있게 되었습니다.
이런 행사 참가할 때마다 정말 많은 배움을 얻고 가슴벅찬 경험을 하게 되는데, 이번 포럼 역시 마찬가지였기에, 후기를 적어볼까 합니다.

# 상당히 주관적인 기준으로 작성한 글이라, 공감하기 어려울 수 있습니다.
# 물론, 제가 잘못 알아들은 내용이나 잘못 설명한 부분이 많을 테니, 이런 부분 알려주시면 감사하겠습니다 :)

Day 1. 11th October - Keynotes & Talks
포럼의 첫째날은 8시 반부터 등록이 시작되었고, 9시 반 키노트로 포문을 열었습니다.


재밌는 건, 통역사가 지원되어서 동시 통역이 지원되었고, 통역해 주시는 내용을 자리에서 들을 수 있도록 라디오를 제공하더군요.
상당히 높은 퀄리티의 통역이었습니다. 약간의 시간차가 있긴 했지만 거의 동시간에 통역이 되어서 들으면서도 조금 놀랐네요.


키노트, 그리고 Linux Foundation 의 발표 스킬
Linux Foundation 의 Jim Zemlin 이 진행했는데, 리눅스의 현재 상황과 리눅스 개발의 의의 등에 대해 이야기 해주셨습니다.

감명깊었던 내용 중 하나는 Upstream 개발에 대한 이야기였습니다.
대부분의 회사가 Open Source Software를 가져가 쓰기만 하거나 자기들 쓸 용도로만 수정하고 공개하지 않거나, 공개하더라도 사용자가 접근할 수 있도록 공개하기만 하고 Upstream(main 개발을 하는 소스코드 저장소의 개발 stream)에는 그 변경내용/개선사항을 공유하거나 merge 시키지 않는 경우가 많은데, 그렇게 함으로써 생기는 비용이 엄청나고, Upstream에 각자의 변경내용을 merge 함으로써 얻을 수 있는 이득이 엄청나다는 이야기입니다.
굉장히 동의합니다. 그러지 않는 환경에서 작업하며 커다란 좌절감을 느꼈던 기억도 있구요.

영어로 진행되는 행사에 갈때마다 느끼는 거지만, native speaker인 발표자들의 말이 비 영어권 국가 진행자의 영어보다 잘 들리는 경우가 많습니다.
다양한 억양, 다양한 국가 외국인의 영어에 익숙하기에 더욱 그들이 듣기 편하게 구사하는 능력도 뛰어날 수 있는걸지도 모르겠습니다.
이 키노트 또한 그러해서, 내 영어 듣기 능력이 생각보다 우월한걸? 하고 근거없는 자신감에 벅차올랐다가 나중에 현실을 마주하고 좌절하기도 했습니다.

또 한가지 신기했던 건, 그 발표 능력이었는데요. 사실, 리눅스는 아무래도 Hacker들만의 성지에 가깝다는 느낌이 있어서 사회성 없는 Hacker 들만 있을 거라는 편견이 조금 있었는데, 스티브 잡스 부럽지 않은(Linux Foundation 멤버를 스티브 잡스와 비교하는 건 당사자에겐 좀 실례가 되지 않을까 싶긴 합니다만...^^;;) 뛰어난 발표 능력과 발표 중간중간의 유머와 조크가 상당히 돋보였습니다.

개인적으로는 이 Jim Zemlin 과 Jon Corbet, Greg Kroah-Hartman, 그리고 Linus Torvalds 형님(호형호제 하는 관계 아니지만, 제 나름의 존경의 일방적 표현입니다^^;)의 발표능력이 상당히 인상깊었습니다.
사실 Linus 형님께선 발표는 안하셨고 Talk 시간만 가지셨기에 발표능력이라 하긴 좀 뭐하긴 합니다만... 그 특유의 포스와 FOSS가... ㅎㅎ


리눅스 개발 참여의 현상황, 리눅스에 기여함으로써 얻는 것들
이후 여러가지 발표와 대담들이 있었습니다.
Jon Corbet 님께선 리눅스의 현재 개발 상황과 앞으로의 전망(특히 3.7) 등에 대해 여러가지 자료 등을 보여주면서 이야기 해 주셨습니다. Volunteer 의 기여가 점점 줄어들고 있다는 이야기도 있었는데, 이어진 커널 개발자들의 패널 대담에서 이에 대해 한편으로는 위기라고 생각할 수 있겠지만, 사실은 Volunteer가 두각을 보이는 즉시 회사에 채용되기 때문이라고 해석하는 게 맞을 것이라는 이야기도 흥미로웠습니다.

대담에서는 여러가지 이야기가 있었고, 몇가지 주제들은 이 대담에서만이 아니라 이후 이어진 발표들과 다음날 이어진 세션에서도 계속해서 이야기 되었는데요. 그 중 하나는 왜 그리도 커널 개발자들(이 경우 maintainer 라 칭하는 게 더 걸맞을 것 같지만)은 뉴비들의 컨트리뷰션에 까칠하냐는 이야기였던 것 같습니다.

나름 큰 맘 먹고 패치를 만들어서 컨트리뷰션 하려 하지만, 이를 리뷰하고 받아주는 커널 개발자들은 보기에 따라선 좀 까칠한 어조/태도로 해당 패치를 reject 하는 경우가 많다는 것이죠.

저도 리눅스에 패치를 보낸 적은 없지만 Android Open Source Project 에 몇개의 패치를 보낸 적이 있는데, 초반에 나름 까칠하다는 느낌을 받았기에 재밌게 들었는데요.

이에 대해 개발자들의 의견의 대부분은, 넘어서야 하는 진입장벽이라는 분위기였던 것 같습니다. 여러모로 동의하는 바입니다. 패치를 처음 contribution 하는 입장에선 왜 내 패치를 받아주지 않는지 굉장히 애석하지만, 사실 머리를 식히고 생각해 보면 그들 말이 맞는 경우가 많거든요.
그렇다고 상처 받을 것도 아니고, Feedback을 잘 해석해보고 이해하고, 논쟁하는 자세가 필요하다는 이야기가 있었고, 이에 대해 99.99% 동의합니다.

패널들과의 대화 이후에는 구글의 허태준님의 키노트도 있었습니다.
Some lines have 81 Characters. 제대로 뿜었습니다.ㅋㅋ
웃음 포인트가 어딘지 궁금하면 500원.


통역이 제공되는 만큼 영어로의 통역도 제공되기에 허태준님은 한글로 키노트를 해주셨는데요. 리눅스 개발을 함으로써 개인이 얻을 수 있는 즐거움과 실질적인 이익, 그리고 기회에 대해 이야기를 해주셨습니다.
즐거움이야 개발에서 즐거움을 느끼는 분들은 너무나도 당연히 아실테고, 메인스트림에서 활동함으로써 그 메인 스트림 개발자 사이에서 social network이 생성되고, 대부분의 메인스트림 개발자들은 뛰어난 능력을 가지고 훌륭한 회사에 소속되어 있는 경우가 많기 때문에, 채용의 기회도, social network에서 얻을 수 있는 지식/기회도 많다는 이야기였습니다.

저는 아직 OSS 쪽에 기여한 바가 별로 없는 뉴비지만, OSS에 기여하려 노력하고, 아주 작은 부분이나마 기여했는데, 그러면서 상당히 많은 즐거움과 기회, 이익을 얻었고, 그런 노력은 구글 코리아에서 마련해 줬던 어느 모임에서 허태준님께 이야기를 들으면서 느꼈기에 여러모로 많은 분께 감사하고 있습니다.
물론 이 감사함은 patch로 갚아야겠죠 :)

발표자료를 github로 공개한 키큰남자, Greg Kroah-Hartman
태준님의 키노트 후에는 Greg Kroah-Hartman의 발표가 있었습니다.
Working upstream saves time and money

리눅스 개발 프로세스에 대한 이야기였는데요. 앞서서 Linux Foundation의 발표력이 장난 아니라고 말씀드렸지만, 개인적으로 이분의 발표력에 여러모로 매료되었습니다.
하이라이트는 둘째날의 발표였습니다만, 이 발표에서부터 느꼈던 게, 깔끔하고 알아듣기 쉬운 발표 내용, 분명한 발음 등의 발표 스킬도 스킬이지만, 개발자를 끌리게 하는 그 무언가, 하드코어 개발자로써의 아우라와 포스, 그리고 geeky한 센스가 넘쳐나더군요.
발표 시작에서부터 github를 통해 발표자료를 공유해 주는 것부터 시작해서 말이죠.
발표 내내 지루할 새가 없었습니다.

Linus Time
어쨌든 이날 행사의 방점은 역시 토발즈 형님이었죠. 제 캘린더 일정의 이름은 Korea Linux Forum이 아니라 '리누스 토발즈 방한' 이었습니다.ㅋㅋ

마지막 시간으로 Intel 의 Dirk Hohndel과 Linus Torvalds 형님의 대담&QnA 세션이 있었습니다.
토발즈 형님은 QnA 세션을 즐기기로 유명하죠. 한국 개발자들 Shy 하다고들 하는데, 질문은 정말 많이 잘합니다. 저도 뭐 하나 질문하려고 손을 다섯번 들었는데 결국 시간이 다 되어서 질문하지 못했습니다 OTL
여러가지 질문과 재밌는 답변이 있었는데, nvidia에 가운데손가락을 친히 사용해주셨던 토발즈 형님의 얼마전 발언에 대한 질문이 좀 기억에 남습니다.
Greg의 geeky한 센스에 대해 앞서 이야기했지만, Geek's King 이라 불리는 토발즈 형님의 그 센스와 아우라 또한 형광등 백개 켠듯 하더군요.


이날 점심시간에는 토발즈 형님이 잠시 모습을 드러냈는데, 사람들이 토발즈 형님과 사진을 찍으려 긴 줄을 서기도 했습니다.
다른 커널 개발자들과 대화하는 중이었기에 좀 당황스럽거나 귀찮았을 수 있는데도 웃으며 사진에 응해주는 토발즈 형님의 대인배 스러운 웃음이 멋지더군요.

저도 한장 함께 찍었습니다 :)
귀찮게 해서 미안해요, 토발즈 형님. 하지만 별 수 없었어요.

행사가 모두 끝난 후, 갑자기 사람들이 토발즈 형님 앞으로 몰려들었습니다. 이번엔 싸인행렬!
줄이 세워지는 징조가 보이자마자 저도 줄을 섰습니다.
어디에 싸인을 받으면 좋을까 고민을 1초 하다가, 맥북에어를 꺼냈습니다. 맥북 밑바닥에 싸인을 해주세요!
토발즈 형님께서 이 기계(맥북 에어)에는 싸인을 하지 않겠다고 하시더군요(암, 그래야 제 토발즈 형님 답죠.ㅋㅋ). 크게 당황했지만 곧바로 제 맥북에어에 리눅스를 설치하고 리눅스 머신으로 사용하겠다고 약속하면서 다시 한번 싸인을 부탁했습니다. 감사하게도 싸인 성공!
좀 우발적으로 한 약속이지만 지켜야겠죠. 당장의 목표는 제 맥북에어에 리눅스를 설치하는 겁니다.
이미 문서는 많은 것 같은데, 조만간 설치하고 작업 내용을 정리해서 공유해 볼까 합니다 :)
Signed-off-by : Linus Torvalds ;)




Day 2. 12th October - Technical Sessions & Party
첫째날은 약간 이론/개념/철학적인 이야기가 주가 되었던 것에 반해, 둘째날은 철저히 기술적인 세션들로 이루어졌습니다.
아침부터 세개의 방으로 나눠서 세개의 세션들이 동시에 진행되었습니다.

Write and submit your first Linux kernel patch
모두 인상깊고 많은 공부가 된 세션들이었습니다만, 하나만 이야기 하자면 아무래도 Greg의 세션이 인상깊었는데요.
아침에 강의장에 혼자 들어갔는데, Greg이 발표 준비를 하고 있더군요.
발표 준비 마치고 나가기 전에 사진 한장!

Greg이 발표한 세션의 주제는 How to submit patches effectively. 첫째날은 전반적인 커널 개발 프로세스를 이야기했다면, 좀 더 practical 하게 패치를 작성하고 보내는 방법, 이 때 주의할 내용 등에 대한 이야기였습니다.
발표 내용은 곧바로 스크린캐스트로 녹화되어서 공개되었습니다.
안타깝게도 소리가 좀 이상합니다.

이 세션이 흥미로웠던 이유 중 하나는, 저도 AOSP에 패치를 몇개 submit하고 merge 되는 경험을 해보고 나서 이를 바탕으로 AOSP에 패치를 보내는 방법 및 요령을 어느 행사에서 발표한 적이 있기 때문이었습니다.
그리고, Greg의 발표에서 상당히 많은 배움을 얻었습니다. 좀 더 실질적이고, interactive 하고, 참여할 수 있는 발표 진행을 보여주더군요.
발표내용은 소리가 좀 이상하지만 위 동영상을 보시면 될테고... 세션이 시작 전에 사람들에게 봉투를 하나 돌리며 그 안에 든 종이조각을 하나씩 가져가라고 하더군요.
받아보니 리눅스 소스코드들 중 파일 하나하나의 경로. 이걸 수정해서 패치를 보내 보랍니다.
복잡한 수정까진 필요없고 일단 코딩스타일 안맞는 것들을 좀 수정해 달라고.
럴수럴수이럴수! 발표에의 집중도도 높이고 커널개발에 진입할 기회도 제공하고! 발표 내용이야 뭐 더이상 말할 게 없구요.

한가지 아쉬웠던 건, 사람들의 반응이 뜨겁진 않았다는 겁니다. 청중도 많지는 않았고, 질문도 넘쳐나진 않더군요. 역시 우리나라에서 Contribution은 아직은 조금 서먹한 topic인가 봅니다.
어느정도 예상했던 바이긴 하지만, 멋진 세션이었던 만큼 더 아쉽더군요.


삼원가든에서 불타는 금요일 PARTY
포럼 스케쥴을 보면서 눈에 띄었던 게 둘째날 저녁 스케쥴이었는데요. 삼원가든으로 이동해서 저녁식사를 하기로 되어 있더군요.
그리고, 첫째날 아침 키노트에서 둘째날 저녁 강남 스타일의 파티를 열 계획이라고.
적당히 고기나 구워 먹겠지 했는데.
정말 이렇게 먹어도 되나 싶을 정도로 고기 먹고, 여성 댄스그룹과 B-boy들의 공연까지 이어지는 정말 멋진 파티였습니다.
무대 뒤쪽에 위치한 작은 연못. 영롱한 빗깔의 잉어가 통통하더군요.

고기를 먹고 나오니 여성 댄스그룹의 공연이 한창!

영웅과 같은 개발자들, 처음 보는 개발자분들과 만나고 사진도 찍고 명함도 나누고 이야기를 나누고.
정말 꿈같은 이틀간의 포럼, 많은 에너지와 열정을 얻은 시간이었습니다.

행사를 주최/후원해주신 많은 관계자들과 회사에 감사의 말씀을 마지막으로 전하고 싶네요.
말로만이 아니라, 항상 이런 자리 마련해주는 관계자/회사 분들께 진심으로 감사하고 있습니다.

#LINUX
#LFKLF