커널 기여 근황

처음 기여를 시작한 11월 말부터 현재까지 약 10개 가까이 되는(시리즈 포함) 패치를 보냈다.

이중에서 현재,

2개 승인

8개 리뷰중

3개 리젝

인데, 생각보다 리뷰가 상당히 까다롭다.

승인 패치

[패치]

https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-nonmm-unstable&id=f34e19c34e4e92338d2ceaab2b95dd7790d262de

kernel/fork.c에 있던 주석 수정인데, 기존의 주석이 함수의 동작을 애매하게 표현했었다.

따라서 함수의 동작과정(mm_release())를 분석하고 그에 맞게 주석을 수정했다.

이건 별다른 리뷰 없이 승인 받았다.

 

[패치]

https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/?h=staging-next&id=69dc48dc550640b1c33e30f32620fe5ef1b068e9

drivers/staging/rtl8327bs 드라이버 기여이다.

기존에 있던 메모리 수동 정렬을 커널 표준 매크로로 변경하는 패치를 진행하였고,

승인 받았다.

 

리뷰 중 패치

여기서부터는 본격적으로 리뷰를 받았다.

 

[패치]

https://lore.kernel.org/linux-staging/20260126163430.3067008-1-s9430939@naver.com/T/#t

기존에 있던 코드의 에러 핸들링이 없어서, 에러 핸들링을 추가했다.

하나를 수정하니 연쇄적으로 caller들까지 전부 수정해야해서 규모가 살짝 커졌다.

v7까지 진행하는동안 쌉고수들의 코드리뷰를 받았다. 마지막이다 하고 v6패치를 제출했는데,

갑자기 "하드웨어 테스트 진행해봤어?" 라고 물어보길래 벙쪘다. 그래도 상황 설명은 잘 했으니 기다려보기.

 

[패치]

https://lore.kernel.org/linux-staging/20260204131347.3515949-1-s9430939@naver.com/T/#t

쓰달대기 없는 Wrapper 함수를 전부 걷어내고 caller도 모두 수정했다.

덕분에 작업 규모가 커졌고, 귀찮아졌다. 이것도 기다려보기.

 

[패치]

https://lore.kernel.org/linux-staging/20260131171153.3729458-1-s9430939@naver.com/

레이스 컨디션 가능성을 없애는 패치1

 

[패치]

https://lore.kernel.org/linux-staging/20260205021620.1165137-1-s9430939@naver.com/

래이스 컨디션 가능성을 없애는 패치2

 

리젝

[패치]

https://lore.kernel.org/linux-staging/20260113133831.3422480-2-s9430939@naver.com/

래퍼 함수 만들었는데, "쓰달대기 없는 래퍼 함수 만들지마라!" 하고 리젝

 

[패치]

https://lore.kernel.org/linux-staging/20260113133831.3422480-3-s9430939@naver.com/

이건 나름 괜찮은 패치, 하지만 하드웨어 테스트 해봤어?

근데 내가 rtl8723bs 하드웨어가 어디있겠나.. (그래서 하드웨어를 어떻게든 구해보고싶다.)

 

[패치]

https://lore.kernel.org/all/20260102062759.3749606-1-s9430939@naver.com/

이건 그냥 주석에있는 오타수정하고 printk->pr_err수정이었는데,
"굳이??"라고 리뷰와서 그냥 접음.

 

[패치]

https://lore.kernel.org/all/20260127055321.2400480-1-s9430939@naver.com/

이건 주석 수정. 기존의 주석이 함수의 동작을 제대로 설명하지 못했다고 느꼈다.

이과정에서 copy_mm의 동작과정, context_switch()의 동작과정을 분석했고,

그에맞게 주석을 새로 달아주었다. 마지막 수정이 2005년도이다 (by Linux Torvals)

-> 역사적으로 문제가 된 적, 헷갈린적이 없다고 리젝당함.

배운 점

의미없는 추상화 하지 말 것.

완벽한 논리보다, "돌아가는 코드"가 중요하다.

잘 돌아가면 굳이 건들지 말 것. ->  효율적으로 만든다면 테스트 필수

커널 코딩 스타일

하나의 함수가 미치는 영향이 생각보다 큼