이전 소절에서 리눅스 커널 소스 코드를 내려받아 여러분의 코드 반영하는 과정을 설명했습니다. 여기서, 필자는 너무나 당연한 질문을 하나 던져 보겠습니다.
리눅스 커널 오픈 소스에 참여해 기여(Contribution)하는 이유는 무엇일까?
이 질문에 여러 가지 대답을 할 수 있습니다만 필자의 생각은 다음과 같습니다.
리눅스 커널 오픈 소스 프로젝트 참여를 통해 많은 것을 배울 수 있습니다.
우리가 수정한 코드가 리눅스 커널 저장소에 반영되는 것 그 자체는 큰 의미는 없다고 생각합니다. 무엇보다 그 과정이 중요합니다.
이번에는 리눅스 커널 오픈 소스 프로젝트 참여를 통해 무엇을 배울 수 있는지 이야기해보겠습니다.
코드 리뷰
리눅스 커널 오픈 소스를 진행하면 세계 정상급 커널 개발자로부터 코드 리뷰를 받을 수 있습니다.
필자가 겪은 한 가지 예를 들어볼까요?
필자는 ext4 파일 시스템 코드를 분석하다가 커널 패닉을 유발하는 BUG(); 코드 다음에 'return -EINVAL' 구문을 제거하는 패치를 메일로 송부했습니다.
diff --git a/fs/ext4/extents_status.c b/fs/ext4/extents_status.c
index a959adc..7f97360 100644
--- a/fs/ext4/extents_status.c
+++ b/fs/ext4/extents_status.c
@@ -781,7 +781,6 @@ static int __es_insert_extent(struct inode *inode, struct extent_status *newes)
p = &(*p)->rb_right;
} else {
BUG();
- return -EINVAL;
}
}
패치의 아이디어는 간단합니다.
BUG(); 가 실행돼서 커널 패닉이 발생하면 'return -EINVAL;' 코드를 실행되지 않는다.
그래서 코드를 삭제하는 것이 좋겠다.
조금 후에 ext4 파일 시스템 메인테이너(Maintainer)인 "Theodore Y. Ts'o" 개발자로 부터 메일이 왔습니다. 코드 리뷰 내용은 다음과 같습니다.
출처: https://lkml.org/lkml/2019/8/22/696
This would not be safe in the case of !CONFIG_BUG. (See init/Kconfig)
It's fair to argue that we shouldn't have CONFIG_BUG --- or
!CONFIG_BUG should still cause the kernel to stop without actually
printing the full BUG information, for those tiny kernel applications
which are really worried about kernel text space.
It also would be fair to argue that we should remove the unreachable
annotation for BUG(), or even, add a *reachable* annotation to catch
code where something something terribly might happen if the kernel is
built with !CONFIG_BUG and we trip against a bug.
But this is a much higher level issue than your sending individual
paches subsystems.
Regards,
코드 리뷰의 내용을 간단히 요약하면 'CONFIG_BUG 컨피그를 비활성화했을 때 동작'을 고려해 보자란 내용입니다.
제안한 패치는 사실 상 거절됐지만 '이 보다' 상세한 코드 리뷰를 받을 수 있어서 참 유익했다고 생각합니다. 또한 코드 리뷰 내용을 읽고 많은 생각을 하게 됐습니다.
이렇게 정상급 리눅스 개발자로부터 다음과 같은 내용이 포함된 상세한 코드 리뷰를 받을 수 있습니다.
코딩 룰
주석문의 내용
코드의 Side-Effect
git 사용법
리눅스 오픈 소스 프로젝트를 참여하면서 자연스럽게 GIT을 익히게 됩니다.
커밋을 생성
커밋 메시지를 작성
GIT Merge
GIT는 리눅스 진영에서 소개된 소프트웨어 형상 관리 프로그램입니다. 하지만 지금은 다른 소프트웨어 개발 분야에서도 GIT를 버전 관리 프로그램으로 많이 쓰고 있습니다.
어떤 소프트웨어 회사이건 반드시 소프트웨어 버전 관리를 하기 마련인데, 개발자들은 이를 잘 다뤄야지 용이하게 개발할 수 있습니다.
개발자 간 communication 및 개발 문화
해외 리눅스 커널 개발자들은 어떤 방식으로 소통하고 개발하는지도 오픈 소스 프로젝트를 통해 알 수 있습니다. 무엇보다 값진 경험입니다.
이제까지 Appendix로 '리눅스 커널 오픈 소스 기여(Contribution)하는 방법'를 설명 드렸습니다. 간단히 소개를 하려 했으나 생각보다 길어 졌습니다.
'리눅스 오픈 소스 프로젝트' 관련 팁이나 유익한 내용을 더 알고 싶으시면 다음 필자의 블로그를 참고하세요.
http://rousalome.egloos.com/category/Kernel_Contribution_Tips
"혹시 궁금한 점이 있으면 댓글로 질문 남겨주세요. 아는 한 성실히 답변 올려드리겠습니다!"
Thanks,
Austin Kim(austindh.kim@gmail.com)
[부록 A] GCC 지시어
[부록 B] 리눅스 커널 실력을 키우는 방법
[부록 C] 리눅스 커널 프로젝트에 기여하기
C.1 리눅스 커널 오픈소스 프로젝트 소개
C.2 설정 방법
C.3 패치 코드를 작성한 후 이메일로 보내기
C.5 리눅스 커널 오픈소스 프로젝트로 얻는 지식
# Reference: For more information on 'Linux Kernel';
디버깅을 통해 배우는 리눅스 커널의 구조와 원리. 1
디버깅을 통해 배우는 리눅스 커널의 구조와 원리. 2
최근 덧글