Submitting patches to the Linux kernel mailing list

저도 처음엔 커널 메일링 리스트가 마치 높은 산처럼 느껴졌어요. "내가 보낸 코드가 전 세계 개발자들에게 공개된다니... 실수하면 어쩌지?" 이런 걱정, 저만 한 거 아니죠? 그런데, 직접 해보니 생각보다 덜 무섭고, 오히려 재밌는 경험이더라고요. 오늘 이 글로 커널 패치 제출의 핵심 절차, 꼭 지켜야 할 규칙, 그리고 실제로 패치를 보내는 방법까지 하나씩 짚어드릴게요.

이 글을 다 읽고 나면, 단순히 기술적인 방법뿐 아니라 커널 커뮤니티와 소통하는 노하우, 패치 작성 시 흔히 하는 실수와 이를 피하는 팁까지 얻어가실 수 있습니다. 완벽하지 않아도 괜찮아요—저랑 같이 한 걸음씩, 실전 경험 쌓아가 보죠!

목차

1. 리눅스 커널 패치 제출 개요
2. 패치 생성: git format-patch 사용법
3. LKML에 패치 제출: git send-email 활용법
4. 커밋 메시지 작성과 규칙
5. 코드 스타일 검사: checkpatch.pl 실전 활용
6. 메일링 리스트 태그(Signed-off-by, Acked-by 등) 완전 정복
7. 코드 리뷰 및 피드백 대응 방법
8. 실제 사용 사례: 드라이버 추가 및 버그 수정
9. 주요 이슈 및 문제 해결 방법
10. 마무리 및 다음 단계

리눅스 커널 패치 제출 개요

여러분, 리눅스 커널에 패치 한번쯤 제출해보고 싶으셨죠? 저도 처음엔 "깃허브에 PR 올리는 거랑 비슷하겠지" 생각했는데, 실제로 해보니 완전 딴판이더라고요. 그래서 오늘은 리눅스 커널 메일링 리스트(LKML)에 패치를 제출하는 과정과 그 중요성, 그리고 제가 겪었던 좌충우돌 경험담까지 풀어볼게요.

리눅스 커널은 전 세계 개발자들이 협력해서 발전시키는, 진짜 대규모 오픈 소스 프로젝트입니다. 우리나라에서도 삼성, LG 같은 대기업 개발자들이 활발히 참여하고 있죠. 이 프로젝트의 핵심은 바로 '패치 제출'과 '리뷰'입니다. 모든 변경 사항은 패치(patch)라는 단위로 쪼개서 제출해야 하고, 메인라인 커널에 합쳐지기 전까지는 정말 깐깐한 리뷰 과정을 거쳐요.

여기서 중요한 건, 그냥 코드만 잘 짜면 끝이 아니라는 거죠. 예전에 커밋 메시지를 대충 썼다가 "설명이 부족하다", "무슨 변경인지 모르겠다"는 피드백을 받은 적이 있어요. 패치를 제출할 땐 명확한 커밋 메시지, 코드 스타일(특히 checkpatch.pl로 검사 가능), 그리고 변경 이유에 대한 충분한 설명이 꼭 필요합니다.

또 하나, 패치는 최대한 작은 단위로 쪼개서 한 번에 하나의 논리적 변경만 담아야 해요. 저도 처음엔 여러 수정사항을 한꺼번에 보내다가 "이건 2개로 나누세요"라는 지적을 받았거든요. 여러분도 혹시 이런 실수 해보셨나요?

리눅스 커널은 github처럼 바로 푸시하는 게 아니라, 메일링 리스트(LKML)에 패치를 보내서 전 세계 개발자들과 리뷰하고 토론하는 게 기본이에요. 여기서 'Signed-off-by:' 태그로 내가 해당 코드에 책임이 있다는 걸 명시하고, 'Cc:'로 관련 개발자들에게 알림을 보내죠. 'Acked-by:'나 'Reviewed-by:' 태그가 붙으면, 그만큼 신뢰받는 패치라는 의미! 저도 처음 'Reviewed-by:' 태그를 받았을 때, 뿌듯함이 남달랐어요.

정리하자면, 리눅스 커널 패치 제출은 단순히 코드 보내는 게 아니라, 글로벌 협업과 신뢰, 코드 품질을 한 번에 챙기는 과정입니다. 저도 아직 배우는 중이고, 실수도 많이 하지만, 하나씩 경험을 쌓다 보면 자연스럽게 익숙해질 거예요. 여러분도 겁먹지 말고, 작은 수정부터 메일링 리스트에 도전해보세요!

💡 실무 팁

• 패치를 작성할 때는 커널 코딩 스타일을 반드시 준수하세요. 'scripts/checkpatch.pl' 도구를 사용해 스타일 위반을 사전에 점검하면 실수 줄일 수 있습니다.
• 커밋 메시지는 변경 이유와 내용을 명확히 설명해야 하며, 첫 줄은 50자 이내로 요약, 본문은 72자 줄바꿈을 지키는 게 좋습니다.
• 패치를 메일링 리스트에 보낼 때는 'git send-email' 명령어를 활용하면, 패치 파일과 메타데이터를 편리하게 전송할 수 있어요.

패치 생성: git format-patch 사용법

이제 git format-patch로 표준화된 패치 파일을 만드는 방법, 차근차근 살펴볼까요?

git format-patch란?

혹시 패치 파일이 뭔지, 왜 필요한지 헷갈리셨나요? 저도 처음엔 "이거 꼭 만들어야 하나?" 싶었는데, 리눅스 커널이나 여러 오픈소스 프로젝트에서는 커밋 내역을 이메일에 첨부할 수 있는 패치 파일로 변환해 주는 명령어가 바로 git format-patch입니다. 실제로 해보면, 커밋별로 0001-xxx.patch 이런 파일이 생기죠. 이걸 메일링 리스트에 첨부하거나 git send-email로 바로 보낼 수 있습니다.

기본 문법

예를 들어, 내 브랜치에서 origin/master부터 HEAD(최신 커밋)까지 패치 파일을 만들고 싶다면:

실제로 해보니, 커밋별로 패치 파일이 쭉 생기더라고요. 처음엔 파일 이름이 왜 이렇게 복잡한가 싶었는데, 나중엔 이게 오히려 관리하기 편하더라고요.

커밋 메시지 작성 예시

커널 커뮤니티는 커밋 메시지 규칙이 엄격합니다. 저도 "에이, 대충 써도 되겠지?" 했다가 여러 번 지적받았어요.
중요 포인트:

• 첫 줄은 50자 이내로 변경 요약 (대문자로 시작, 마침표 없이)
• 그 아래 빈 줄 하나
• 바디에는 변경 이유, 동작 방식, 영향 범위 등을 명확하게!

예시:

이거 포맷 맞추느라 몇 번이나 커밋을 다시 만들었던 기억, 아직도 생생해요. 여러분도 처음엔 헷갈릴 수 있지만, 금방 익숙해질 거예요.

"Signed-off-by" 서명, 왜 필요할까요?

이 서명은 "내가 이 패치를 제출했고, 책임질게요!"라는 의미입니다. 커널 패치 제출할 때는 필수예요.
추가하는 방법은 두 가지:

1. 커밋할 때 바로 추가

   git commit -s
   

2. 이미 커밋한 경우

   git commit --amend -s
   

커밋 메시지 마지막에
Signed-off-by: 이름 <이메일>
이렇게 자동으로 들어갑니다. 저도 이거 까먹어서 패치 다시 만든 적 한두 번이 아니에요. 여러분은 꼭 한 번에 성공하시길!

잠깐, 정리!

• git format-patch로 표준화된 패치 파일 만들기
• 커밋 메시지는 커널 컨벤션에 맞추기
• Signed-off-by 서명 꼭 추가하기

실제로 해보면, "아, 이게 이렇게 돌아가는구나" 싶은데, 처음엔 헷갈릴 수 있어요. 저도 아직 배우는 중이지만, 실수하면서 익히는 게 제일 빠른 것 같더라고요! 혹시 막히는 부분 있으면 저처럼 구글링이나 네이버 검색도 적극 활용해보세요.
여러분도 멋진 패치 만들어서 오픈소스 커뮤니티에 기여해보시길 응원합니다! 🚀

💡 실무 팁

• 패치 생성 전 로컬 브랜치를 최신 upstream 상태로 리베이스해서 커밋 이력을 깔끔하게 유지하세요.
• 커밋 메시지 본문은 72자 내외로 줄바꿈해서 가독성을 높이고, 줄 바꿈 없이 긴 문장은 피하세요.
• 여러 커밋을 한꺼번에 패치로 보낼 때는 커밋 순서가 의도한 대로 정렬되어 있는지 꼭 확인하세요.

LKML에 패치 제출: git send-email 활용법

이제 git send-email로 리눅스 커널 메일링 리스트(LKML)에 패치를 제출하는 과정을 차근차근 알아볼까요?
저도 처음엔 "도대체 이메일로 패치 보내는 게 왜 이렇게 복잡하지?" 싶었는데, 한 번 해보고 나니까, 아~ 이런 이유가 있었구나 싶더라고요.
특히, 한국에서 메일 서버 인증이나 포맷 관련해서 자주 막히는 부분이 있어서, 저만 겪은 건 아닐 거예요. 다들 한 번쯤은 헤매셨죠?

1. git send-email 환경 설정

패치 메일 보내려면 우선 git send-email부터 설정해야겠죠?
여기서 제일 중요한 게 SMTP 서버 설정이에요.
저는 구글 지메일을 많이 쓰는데, 네이버 메일이나 회사 메일 쓰시는 분들도 비슷하게 설정하시면 됩니다.

저는 처음에 일반 비밀번호 썼다가 "인증 실패" 메시지 엄청 받았어요.
지메일이면 앱 비밀번호 만들어서 써야 합니다!
네이버는 IMAP/SMTP 사용 설정도 꼭 해두시고요.

2. 패치 메일 작성 & 필수 헤더

메일 포맷 규칙이 정말 까다로워요.
Subject에는 꼭 [PATCH] 넣으셔야 하고, From/To/Cc 제대로 지정 안 하면 리턴당합니다.
제가 실수했던 것 중 하나가 Cc에 메인테이너 빼먹어서 답변 못 받은 적 있었거든요.

예시 커밋 메시지:

메일 보낼 때 이렇게 써야 해요:

정리하자면:

• To: LKML 주소 필수
• Cc: 관련 메인테이너, 리뷰어 꼭 포함!
• Signed-off-by: 본인 정보 누락 금지

3. 패치 전송 및 확인

패치 보냈다고 끝이 아니에요!
저는 예전에 메일이 스팸으로 분류되어서, 메인테이너가 "메일이 안 왔다"고 하더라고요.
git send-email 실행 로그 마지막 줄 잘 확인하시고요,
메일 클라이언트(네이버, 지메일 등)에서 "보낸 편지함" 꼭 체크해보세요.

그리고, LKML 아카이브나 lore.kernel.org에서 내 패치가 올라왔는지 검색해보는 것도 습관들이면 좋아요.
메일이 안 뜬다? SMTP 설정, 헤더, 제목 다시 점검!

실수하면서 배운 한 가지 팁

메일 본문 엔코딩 문제로 패치가 깨져서 커밋이 적용 안 되는 경우 많아요.
--compose 옵션 쓰면, 에디터에서 메일 본문을 직접 수정할 수 있어서 더 안전했어요.

솔직히, 아직 저도 매번 완벽하게 보내는 건 아니에요.
근데 실수하면서 하나씩 배우게 되더라고요.
여러분도 겁먹지 말고, 차근차근 따라 해보시길!
궁금한 점 있으시면, 댓글로 남겨주세요~

💡 실무 팁

• SMTP 설정 시 구글 계정을 사용할 경우 앱 비밀번호를 생성하고 이를 SMTP 비밀번호로 사용해야 합니다.
• 패치 메일 제목에 '[PATCH v2]' 등 버전 정보를 명확히 표기하여 리뷰어가 변경 이력을 쉽게 파악할 수 있도록 하세요.
• git send-email 실행 후 출력되는 로그를 꼼꼼히 확인하여 인증 오류나 메일 전송 실패 여부를 즉시 파악하세요.

커밋 메시지 작성과 규칙

이제 커밋 메시지 작성과 규칙에 대해 본격적으로 얘기해볼게요.
여러분, "커밋 메시지 좀 대충 써도 되지 않나?" 이런 생각 해보셨죠? 저도 예전에 그랬거든요. 근데 나중에 내가 쓴 코드나 남이 쓴 커밋 로그를 다시 볼 때, 대충 썼던 메시지 때문에 진짜 곤란했던 경험이 한두 번이 아니었어요.

변경 사항을 명확히 설명하는 법

커밋 메시지의 핵심은 "이 변경이 뭘 하는 건지" 딱 한눈에 알 수 있게 써야 한다는 겁니다. 보통 제목 줄(Subject line)은 50자 이내로 요약해서 쓰고, 본문은 줄마다 72자 이내로 끊어서 좀 더 자세히 설명하면 좋아요.

예시:

제목 줄은 명령형 현재 시제로 작성하는 게 원칙이에요. "Fixed"나 "Fixes"가 아니라 "Fix"처럼 동사 원형으로, 마치 "이 커밋이 지금 이걸 한다"는 느낌으로 쓰는 거죠.

본문에서는 "왜 이 변경이 필요한지"를 꼭 포함하세요.

이렇게 구체적으로 어떤 문제가 있었고, 그걸 어떻게 해결했는지 써주면 나중에 누가 봐도 이해가 쉽습니다.

Signed-off-by의 의미와 작성법

이제 중요한 서명, Signed-off-by에 대해 알아볼까요?
이건 Linux 커널에 패치를 올릴 때 "이 코드는 내가 책임지고 올린다"라는 의미예요.
서명 방식은 아주 간단해요.

git에서 git commit -s 옵션을 쓰면 자동으로 추가돼요.
저는 이걸 깜빡하고 그냥 커밋했다가, 코드 리뷰에서 "Signed-off-by 빠졌어요"라는 피드백을 받았었죠. 그 뒤론 습관처럼 -s 옵션을 꼭 씁니다.

문법 및 스타일 가이드라인

이 부분이 처음엔 제일 헷갈렸어요.

• 제목은 명령형 현재 시제
• 본문은 한 문장에 한 줄
• 줄 끝에 공백 없이
• 탭 대신 공백
• 불필요한 감정이나 사적인 얘기 X

특히, 본문에 "I think"나 "maybe"처럼 추측성 문장, 감정 표현은 빼는 게 좋아요.
버그 트래킹 번호나 참고 링크가 있으면 본문 끝에 붙여두면 나중에 추적하기도 편하더라고요.

정리하자면,

• 커밋 메시지는 명확하고 일관성 있게
• Signed-off-by는 꼭 챙기고
• 문법/스타일 가이드도 잊지 마세요

저도 아직 실수도 하고 배우는 중이지만, 이 규칙만 지켜도 코드 리뷰가 훨씬 수월해진다는 거, 경험상 장담합니다!
실수하더라도 조금씩 개선해보세요.
이거 해보면 실력이 진짜 늘어요!

💡 실무 팁

• 커밋 메시지 제목은 50자 이내로 작성하고, 본문은 72자 이내에서 줄바꿈하여 가독성을 높이세요.
• git commit -s 옵션을 사용하여 Signed-off-by 라인을 자동으로 추가하면 실수를 줄일 수 있습니다.
• 커밋 메시지에 변경 이유와 영향을 명확히 기술하여 리뷰어가 변경 의도를 쉽게 이해할 수 있도록 하세요.

코드 스타일 검사: checkpatch.pl 실전 활용

휴, 여기까지 따라오셨나요? 이제 코드 스타일 검사 도구, checkpatch.pl을 써볼 차례입니다.
처음엔 "이거 꼭 해야 하나?" 싶었는데, 실제로 커널 메일링 리스트에 패치 보냈다가 스타일 문제로 퇴짜 맞은 적이 한두 번이 아니에요.
여러분도 이런 경험 있으시죠?

checkpatch.pl이란?

checkpatch.pl은 리눅스 커널 소스의 코딩 스타일을 자동으로 검사해주는 스크립트입니다.
커널 소스 루트의 scripts/checkpatch.pl에 있어요.

사용법

혹은, 좀 더 간단하게:

실제로 해보면, 스타일 위반이나 경고가 쭉 출력됩니다.
처음엔 "이게 뭐가 문제지?" 싶은 메시지도 있는데, 자주 나오는 것만 익혀두면 금방 적응돼요.

자주 발생하는 스타일 문제 예시

• 탭 대신 공백 사용: "ERROR: code indent should use tabs where possible"
• 줄 끝에 공백: "WARNING: trailing whitespace"
• 80자 초과 라인: "WARNING: line over 80 characters"
• 커밋 메시지 포맷 오류: "ERROR: Missing Signed-off-by line"
• 함수 선언 스타일: "WARNING: function definition argument 'foo' should also have an identifier name"

저는 처음에 탭/공백 혼용 때문에 에러가 계속 나서, 3시간 넘게 삽질했던 기억이 납니다...
여러분도 checkpatch.pl로 미리 점검하면, 메일링 리스트에서 스타일 문제로 퇴짜 맞는 일은 확실히 줄어들 거예요.

💡 실무 팁

• checkpatch.pl은 패치 파일뿐 아니라, 소스 파일에도 직접 적용할 수 있습니다.
• --strict 옵션을 붙이면 더 엄격하게 검사합니다.
• 경고(WARNING)는 무시해도 되는 경우가 있지만, ERROR는 반드시 수정하세요.

메일링 리스트 태그(Signed-off-by, Acked-by 등) 완전 정복

이제 메일링 리스트에서 자주 보이는 태그들, 하나씩 정리해볼게요.
처음엔 이게 무슨 의미인지 몰라서 그냥 넘겼는데, 알고 보니 커뮤니케이션과 신뢰의 핵심이더라고요.

주요 태그와 의미

• Signed-off-by:

  • "이 패치는 내가 작성했고, 책임집니다"라는 의미.
  • 패치 제출자라면 무조건 넣어야 해요.

• Acked-by:

  • "이 패치에 동의합니다"라는 의미.
  • 주로 서브시스템 메인테이너나 관련 개발자가 추가합니다.

• Reviewed-by:

  • "코드 리뷰를 했고, 내용에 동의합니다"라는 의미.
  • 리뷰어가 직접 추가하거나, 패치 제출자가 리뷰어의 동의를 받아 추가합니다.

• Tested-by:

  • "직접 테스트해봤고, 문제 없습니다"라는 의미.
  • 실제 하드웨어나 환경에서 테스트한 사람이 추가합니다.

• Reported-by:

  • "이 이슈를 처음 발견한 사람"을 명시합니다.

• Cc:

  • "이 패치에 관심이 있을 법한 사람"에게 알림을 보냅니다.

사용 예시

저는 처음엔 "이거 누가 넣어야 하지?" 헷갈렸는데,

• 내가 작성한 패치엔 Signed-off-by는 무조건!
• 리뷰어가 "좋아요" 하면 Reviewed-by 추가 요청
• 메인테이너가 "OK" 하면 Acked-by 추가

이렇게 정리하니 한결 명확해졌어요.

💡 실무 팁

• 태그는 커밋 메시지 본문 마지막에, 한 줄씩 추가하세요.
• 리뷰나 테스트를 받은 뒤에는 꼭 해당 태그를 추가해서 신뢰도를 높이세요.
• get_maintainer.pl 스크립트로 관련 메인테이너와 리뷰어를 자동으로 찾을 수 있습니다.

코드 리뷰 및 피드백 대응 방법

이제 코드 리뷰 및 피드백 대응 방법에 대해 알아볼까요?

솔직히 저도 처음에 Linux 커널 메일링 리스트에 패치 보내고 리뷰 받을 때, 좀 떨렸어요. 리뷰어 코멘트가 오면 "아, 어디가 잘못됐지?" 이런 생각부터 들고요. 다들 이런 경험 있으시죠? 그런데 리뷰어의 의견은 내 코드를 까내리려는 게 아니라, 커널 품질을 같이 높이자는 의도라는 점, 꼭 기억하세요. 저도 처음엔 감정적으로 받아들여서 속상했는데, 나중에는 의견을 적극적으로 수용하고 빠르게 반영하는 게 진짜 중요하다는 걸 알게 됐어요.

예를 들어 리뷰어가 "이 부분 변수명을 더 명확하게 해주세요"라고 하면, 그냥 "네, 반영했습니다" 하고 끝내지 말고, 커밋 메시지에 'Reviewed-by: 리뷰어이름' 같은 태그를 꼭 추가하세요. 그리고 어떤 부분을 어떻게 바꿨는지, 왜 바꿨는지 커밋 메시지에 친절하게 적어두면 나중에 다른 사람들이 봤을 때도 투명하고 신뢰가 쌓이더라고요.

정리하자면,

• 리뷰어 코멘트는 열린 마음으로 받아들이기
• 반영 시 커밋 메시지에 'Reviewed-by' 등 태그 추가
• 변경 사유와 내역 명확하게 기록하기

리뷰하다 보면 의견 충돌도 있고, 비슷한 작업을 누군가 이미 하고 있는 경우도 있더라고요. 저도 예전에 같은 기능 패치 두 명이 동시에 보내서, 중복 작업으로 고생한 적이 있었어요. 그래서 메일링 리스트를 자주 확인하고, 비슷한 작업하는 분 있으면 미리 "저 이거 작업 중인데, 어떻게 할까요?" 이렇게 한 번씩 소통해두면 진짜 충돌이 많이 줄어요. 그리고 'git rebase -i'로 커밋 정리해서 패치 시리즈를 깔끔하게 만들면, 리뷰어들도 이해하기 훨씬 쉽죠.

피드백 주고받는 법!
처음엔 "이 부분 잘못됐어요"만 들리면 기분이 좀 그렇지만, 건설적으로 접근하면 서로 윈윈이에요. 예를 들어 "이 함수가 너무 길어서 유지보수가 어려울 수 있는데, 두 개로 나눠보는 건 어떨까요?" 이렇게 대안을 제시하면 훨씬 받아들이기 좋죠. 저도 리뷰할 때는 꼭 장점 한두 가지도 같이 언급하려고 해요. 실제로 이렇게 하니까 상대방이 더 열린 마음으로 의견을 받아들이더라고요.

혹시 리뷰 코멘트가 이해 안 간다? 그럼 그냥 지나치지 말고 "이 부분 좀 더 설명해주실 수 있나요?" 이렇게 추가 질문하세요. 필요하면 IRC나 컨퍼런스 콜로 얘기하는 것도 진짜 도움 많이 돼요. 저도 실시간으로 얘기하다가 오해가 풀린 적이 많거든요.

아직 저도 배우는 중이지만, 실수하면서 하나씩 깨달은 건 결국 소통과 투명함, 그리고 열린 마음이 코드 리뷰의 핵심이라는 거예요. 다들 같이 성장해가면 좋겠네요!

💡 실무 팁

• 패치 제출 전 'checkpatch.pl' 스크립트를 이용해 스타일과 경고를 사전 점검하세요.
• 리뷰어의 코멘트에 대해 빠르게 응답하고, 변경사항을 반영한 새 패치를 신속히 재전송하세요.
• 메일링 리스트 토론을 주기적으로 모니터링하여 유사한 작업이나 의견 충돌을 사전에 파악하세요.

실제 사용 사례: 드라이버 추가 및 버그 수정

실제로 제가 겪었던 사례 하나 공유할게요.
처음엔 USB 드라이버에 작은 버그를 고치려고 패치를 만들었어요.
checkpatch.pl로 스타일 검사했더니, 탭/공백 문제, 80자 초과 라인, 커밋 메시지 포맷 등등 경고가 쏟아지더라고요.
이거 수정하느라 3시간 넘게 걸렸습니다.
그래도 다행히, 메일링 리스트에 올리고 나서 리뷰어가 "코드 스타일 잘 맞췄네요"라고 해주셔서 뿌듯했어요.

또 한 번은, 드라이버에 새로운 기능을 추가했는데, 커밋 메시지에 변경 이유를 제대로 안 써서 "이게 왜 필요한지 설명이 부족하다"는 피드백을 받았어요.
그때는 "아, 그냥 기능만 추가하면 되는 게 아니구나"라는 걸 뼈저리게 느꼈죠.

여러분도 처음엔 실수할 수 있지만, 하나씩 고쳐가면서 배우면 됩니다.
실패해도 괜찮아요. 저도 아직도 실수합니다!

주요 이슈 및 문제 해결 방법

초보자가 자주 겪는 문제, 그리고 해결책을 모아봤어요.

• SMTP 인증 오류

  • 앱 비밀번호/SMTP 설정 꼼꼼히 확인!
  • 메일 서버에서 보안 설정(2단계 인증 등)도 체크하세요.

• checkpatch.pl 경고/에러

  • 에러는 반드시 수정, 경고는 가능하면 수정
  • 스타일 문제는 에디터 설정(탭/공백, 자동 줄바꿈 등)으로 예방

• 커밋 메시지 포맷 오류

  • 커밋 메시지 템플릿 만들어두면 실수 줄일 수 있어요.

• 메일이 스팸함으로 분류

  • 보낸 편지함, 스팸함 꼭 확인
  • 메일 헤더, 제목, 본문 포맷 점검

• 패치가 메인테이너에게 전달 안 됨

  • get_maintainer.pl로 관련자 자동 검색
  • To/Cc에 빠진 사람 없는지 확인

• 패치 시리즈 순서 꼬임

  • git rebase -i로 커밋 순서 정리
  • format-patch로 다시 생성

실제로 저도 SMTP 인증 때문에 반나절을 날린 적이 있어요.
그때 "이거 왜 안 되지?" 하다가, 알고 보니 비밀번호가 아니라 앱 비밀번호를 써야 했던 거였죠.
여러분도 막히면 너무 조급해하지 말고, 천천히 하나씩 점검해보세요.
휴, 복잡하죠? 천천히 다시 볼게요.

마무리 및 다음 단계

이번 글에서는 리눅스 커널 패치 제출 과정을 처음부터 끝까지 단계별로 살펴봤습니다.
git format-patch와 git send-email을 활용한 패치 생성 및 제출, 커밋 메시지 작성 규칙, 코드 스타일 검사, 메일링 리스트 태그, 코드 리뷰 피드백 대응, 그리고 실제 사례와 자주 겪는 문제 해결까지 모두 다뤘어요.

이제 여러분은 커널 소스코드 빌드와 모듈 작성 경험을 바탕으로, 직접 LKML에 패치를 제출할 수 있는 실질적인 역량을 갖췄습니다.
오늘 배운 내용, 꼭 실습해보세요.
여러분의 작은 기여가 오픈소스 생태계에 큰 변화를 가져올 수 있습니다!
실수해도 괜찮으니, 도전해보세요.
저도 계속 배우고 있습니다.
함께 성장해요!

📚 참고자료 및 추가 학습

공식 문서

• Submitting Patches to the Linux Kernel
• Linux Kernel Newbies - How to Submit a Patch

튜토리얼

• 🎥 How to Submit a Patch to the Linux Kernel
• 📄 A Beginner's Guide to Contributing to the Linux Kernel
• 📄 Linux Kernel Patch Submission Workflow

유용한 도구

• 🔧 git
• 🔧 patch
• 🔧 checkpatch.pl
• 🔧 get_maintainer.pl

커뮤니티

• 🌐 Linux Kernel Mailing List (LKML)
• 💭 Kernel Newbies
• 🟠 r/linuxquestions

🔗 관련 주제

Linux 커널 개발 환경 구축 및 소스 코드 이해

커널 패치를 제출하려면 먼저 개발 환경을 세팅하고, 커널 소스의 구조와 빌드 방법을 이해해야 합니다.

Git을 활용한 패치 생성 및 관리

Linux 커널 개발은 Git을 기반으로 하므로, 패치 작성과 관리, 브랜칭, rebase 등 Git 활용법이 필수적입니다.

커널 코딩 스타일과 체크패치(checkpatch) 사용법

커널 패치의 품질을 높이기 위해 코딩 스타일을 지키고, checkpatch.pl 도구로 자동 검사를 수행하는 방법을 익혀야 합니다.

Linux kernel mailing list(LKML) 활용 및 커뮤니케이션 방법

패치 제출과 리뷰는 메일링 리스트에서 이루어지므로, 메일링 리스트 구독, 메일 포맷, 토론 방법 등을 익혀야 합니다.

📈 다음 단계

1. 자신만의 테스트 패치 작성 및 LKML에 제출
2. 다른 개발자의 패치 리뷰 참여
3. 서브시스템별 메인테이너와 협업 경험 쌓기
4. 커널 개발자 워크샵, 컨퍼런스 참석
5. 자동화된 테스트 환경 구축 및 활용

읽어주셔서 감사합니다!
여러분도 리눅스 커널 패치, 도전해보실 준비 되셨죠?
실수해도 괜찮으니, 같이 성장해봐요.
질문이나 경험담, 댓글로 언제든 남겨주세요!