리눅스 커널은 git 을 통해 버전이 관리되지만 github 는 사용하지 않는 프로젝트이다. 따라서 git commit 과 git push & pull 을 통해 개발이 이뤄지지 않는다. 대신 git format-patch 와 git send-email 혹은 다른 email 클라이언트를 통해 commit 아닌 patch 라는 단위를 mailing list 에 올리게 된다.
패치에 있어 알아야 될 기본적인 사양들을 적어 놓았다. 자세한 사항은 다음을 참고하길 바란다: Submitting patches: the essential guide to getting your code into the kernel
1. 전체적인 workflow
- 패치 생성
- 해당 패치에 대한 메인테이너 확인
- 패치 메일 전송
reviewer들의 리뷰
여기에서reviewer가 수정을 요구하면 패치 수정 후 3번으로- 패치 병합
여기에서 패치가 병합된다고 하더라도 mainline 으로 바로 올라가는 것은 아니고 이런 저런 서브트리를 타고 올라가서 최종적으로 linux 에 올라가게 된다.
2. 메인테이너 찾기
수정하려는 파일이 어떤 메인테이너에 의해 관리되는지 확인하기 위해 ./script/get_maintainer.pl -f <filename> 으로 확인한다.
3. 커밋하기
패치 이전에 커밋을 만들긴 해야 한다. 커밋을 바탕으로 패치를 구성하기 때문이다. 따라서 파일을 수정하고 git commit -s -v 명령으로 커밋을 한다. -s 명령은 Signed-off-by 를 추가해주고 -v 는 커밋 메세지를 입력하는 창에서 diff 를 보이게 한다.
git commit -s -v \
--trailer <token>=<value> 커밋 메세지 제목은 subsystem: summary phrase 의 형식을 가지면 된다. 잘 모르겠다면 이전에 다른 이들이 작성한 커밋 메세지를 참고하면 좋다.
- Trailer
커밋을 작성할 때에는 다음의 Trailer 을 추가할 수 있다.
| Trailer | Description |
|---|---|
Signed-off-by | 본인의 이름을 작성한다. -s 로 추가 가능하다. |
Reviewed-by | 리뷰어가 남기는 트레일러. |
Suggested-by | 아이디어 제안자의 이름을 적는다. |
CC | 참조자를 적는다. |
Acked-by | 메인테이너가 남기는 트레일러. |
Fixes | 문제가 되는 커밋을 수정했을 때 남기는 트레일러. commit id 뿐만 아니라 header 도 같이 남긴다. |
자세한 사항은 다음을 참고하길 바란다: https://www.kernel.org/doc/html/v4.19/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by
4. 패치 생성하기
git format-patch \
--subject-prefix=<prefix> \
--cover-letter \
--reroll-count=<n> \
--numbered \
--output-directory <dir> \
-<n> 위 명령으로 패치를 생성하게 되면 패치는 <output> 에 생성된다. 생성된 패치에 대해 ./script/checkpatch.pl 을 수행해야 하며 만약 경고가 발생한다면 적절하게 수정해야 한다.
--subject-prefix는 default 가PATCH이다.--reroll-count는subject-prefix뒤에v<n>을 추가한다.subject-prefix가PATCH이고reroll-count가3이라면 결과는PATCH v3이 된다.--numbered를 지정하게 되면 패치별로 숫자를 부여한다.\[PATCH n/m\]과 같은 형식으로 번호가 붙게 된다.-<n>은HEAD를 기준으로 몇 개의commit을patch로 구성할지를 뜻하는데 숫자가1보다 크면 여러 개의patch가 생성되며 위에서--numbered를 지정했다면 앞서 말한 바와 같이 숫자가 레이블링 된다.--cover-letter는[PATCH 0/5]와 같이0으로 인덱스되며 여러 패치들을 하나로 묶어서 보낼 때 첫 번째 패치는cover patch가 되며 여기에 패치 전체에 대한 내용을 적으면 된다.--output-directory는 말 그대로 패치가 저장될 디렉토리를 지정한다.
자세한 내용은 다음을 참고하길 바란다: https://git-scm.com/docs/git-format-patch
- Note
--- 이후에 패치의 버전별 차이점이나 기타 등등(P.S.) 을 작성할 수 있다.
5. 패치 메일 보내기
git send-email \
--smtp-encryption=tls \
--to=<maintainer> \
--cc=<mailing list> \
--chain-reply-to \
--in-reply-to=<message id> \
<patch>to에는 2번에서 찾은 메인테이너의 이메일 주소를 쓰면 된다.cc는 참조자로 이메일을 받게 되는 사람을 포함하는데 여기에는 메일링 리스트, 리뷰어 등이 들어간다.in-reply-to는 답장을 할때 쓸 수 있다. 이렇게 전달된 메일은 쓰레드를 만드는데subsystem마다v2패치에 대해in-reply-to를 쓰지 않기를 원하는 곳도 있으므로 잘 확인해봐야 한다.message id는gmail기준메일 원본 보기를 통해 확인할 수 있다.
자세한 정보는 다음의 글을 읽어보길 바란다:
https://git-scm.com/docs/git-send-email
필자가 추천하는 방법은 메일을 바로 보내는 것 이 아닌 일단은 본인한테 먼저 보내는 것 을 추천한다. 처음에는 코드 문제보단 패치와 메일 양식에 문제가 있는 경우가 대부분이므로 우선 본인한테 보낸 후 확인해보고 문제가 없다면 그때 보내는 것을 추천한다.
6. 답장하기 (gmail)
답장을 할 때에는 답장할 패치에 대해 Reply 버튼을 눌러서 답장을 하면 되는데 일반적으로 Gmail 설정을 제대로 하지 않으면 답장할 때의 언어가 한국어로 나간다. 예를 들어 인용 시간이 대표적이다.
이런 식으로 메일이 날라가게 되면 안되므로 Gmail 의 입력도구 설정을 다음과 같이 변경한다:
또한 계정이름이 한국어로 되어 있으면 실제 이메일을 보내는 사람도 영어가 아니라 한국어로 날라가기 때문에 이 또한 명시적으로 변경해주어야 한다:
여기에 정리한 정보는 대부분 기능적인 것들이고 실제로 어떻게 커밋 메세지를 작성하고 패치를 구성하는지는 서브 시스템에 조금씩 다를 수 있으므로 이전에 작성됐던 메세지들과 패치 구조를 잘 분석하는 것이 더 중요하다.
