필자가 이전에 작성한 글에서 리눅스 커널의 버전이 어떻게 관리되는지 소개했다. 그렇다면 다음 릴리즈에 들어갈 패치는 어디에서 태어나는 것일까?
이 글에서는 패치 라이프 사이클과 next-tree, staging-tree 에 대해 소개할 예정이다.
1. 패치 라이프 사이클
패치는 개발자의 키보드에서 바로 mainline 커널로 들어가지 않는다. 그전에 패치에 대한 리뷰 과정 을 거치는데 사소한 수정이라면 빠르게 mainline 에 입성하지만, 규모가 크고 논란의 여지가 많은 변경의 경우 수 년의 시간이 걸리기도 한다.
* 설계와 리뷰
1. 설계
패치는 mainline 의 요구사항(버그 수정이나 새로운 기능)과 이러한 요구사항을 만족하는 방법을 제시해야 한다는 것이다. 설계는 혼자해도 상관 없지만 가능하다면 커뮤니티에 정보를 공개한 뒤에 작업하는 것이 더 좋다. 그래야 이후에 재설계하는 시간을 줄일 수 있다.
2. 초기 리뷰
패치는 연관된 메일링 리스트에 게시되고, 해당 메일링 리스트의 개발자들은 여기에 대한 본인의 의견을 제시할 것이다. 이 과정에서 패치에 대한 문제점을 지적할 수도 있고 그 밖에 다양한 의견을 제시할 수 있다. 만약 패치의 변경이 필요하다는 피드백을 받았다면, 그렇게 변경을 하거나 혹은 그렇게 하면 안되는 이유를 설명할 수 있어야 한다. 만일 패치에 대해 불평하는 리뷰가 하나도 없음에도 패치가 병합되지 않더라도, 패치가 바로 적용될 수 있도록 현재 커널의 버전으로 업데이트 하고 리뷰 및 병합을 위한 지속적인 노력을 기울여야 한다.
3. 더 광범위한 리뷰
패치가 mainline 에 들어갈 준비가 되었다면 관련된 서브 시스템의 메인터이너가 이를 승인해야 한다. (그러나 패치를 승인한다고 해서 mainline 까지 올라간다는 보장은 없다.) 패치를 승인하면 메인테이너의 서브시스템 트리와 -next 트리에 올라간다. 이 과정에서 패치는 더 광범위한 리뷰로 이어지고 다른 사람이 수행 중인 작업과 이 패치를 통합하는 과정에서 발생한 문제를 발견하게 된다.
* 병합 그 이후
- mainline
성공적인 패치는 Linus Torvalds 에 의해 관리되고 있는 mainline 저장소로 병합된다. 더 많은 의견과 문제점들이 이 시점에 수면 위로 오를 수 있다. 개발자는 이러한 문제에 대해 신속하게 대응하고 발생한 문제를 해결하는 것이 중요하다.
- stable release
패치로 인한 영향을 받는 잠재적인 유저들이 더 많아졌기에, 다시 한번 새로운 문제가 발생할 수 있다.
- Long-term maintenance
병합된 이후, 해당 코드를 잊게될 가능성이 있으나 이러한 행동은 개발자 커뮤니티에 좋지 않은 인상을 남긴다. 병합된 코드가 당장은 유지보수의 짐을 줄여주지만, 한편으로는 API 변화에 따른 문제를 수정해야 한다. 따라서, 원래 개발자는 코드가 장기적으로 유용하게 만들기 위해 코드에 대한 책임을 계속해야 한다.
커널 개발자(또는 그들의 고용주)가 저지르는 가장 큰 실수 중 하나는 위에서 소개한 전체 프로세스를
메인라인으로 병합하기라는 단일 단계로 줄이려는 일체의 시도이다. 이러한 접근 방식은 여지없이 관련된 모든 사람들에게 좌절감만 느끼게 한다.
2. 어떻게 패치가 커널로 들어가는가
패치를 mainline kernel 저장소로 병합할 수 있는 사람은 Linus Torvalds 단 한 사람 밖에 없다. 하지만 실제로 Linus 본인이 직접 선택하여 병합한 패치는 전체 패치 중 극히 일부이다. (2.6.38 기준, 9,500 개가 넘는 패치 중 단 112 개만이 Linus 본인이 직접 선택하여 병합한 패치이다.)
커널 프로젝트는 한 명의 개발자가 다른 사람의 도움 없이 모든 패치를 검사하고 선택할 수 없을 정도의 규모로 커졌다. 커널 개발자들은 이러한 상황에 대처하기 위해, 신뢰의 사슬을 중심으로 한 계급 시스템을 구축했다.
- 메인테이너 (Maintainer)
커널 코드는 네트워킹, 특정 아키텍처 지원, 메모리 관리, 비디오 장치 등의 서브 시스템 집합으로 나뉘어진다. 대부분의 서브 시스템에는 지정된 메인테이너 (Maintainer)가 있는데, 이는 해당 서브 시스템 내의 코드에 대한 전반적인 책임을 지는 개발자이다. 이러한 서브 시스템 메인테이너는 자신이 관리하는 커널 부분에 대한 게이트키퍼(느슨한 방식으로)이다. 이들은 mainline 커널에 포함할 패치를 승인하는 사람들이다.
merge window 가 열리면 최상위 관리자는 리포지토리에서 병합을 위해 선택한 패치를 pull 하도록 linus 에게 요청한다. 리누스가 동의하면 패치 스트림이 리포지토리로 흘러들어 mainline 커널의 일부가 된다. pull request 를 통해 수신된 특정 패치에 대한 linus 의 관심은 때에 따라 다르지만, 때때로 매우 자세히 살펴본다는 것은 분명하다. 그러나 일반적으로 linus 는 서브 시스템 메인테이너가 잘못된 패치를 업스트림으로 보내지 않을 것이라 믿는다.
- 신뢰의 사슬 (chain of trust)
서브시스템 메인테이너는 차례로 다른 메인테이너로부터 패치를 가져올 수 있다. 예를 들어, 네트워킹 트리는 네트워크 장치 드라이버, 무선 네트워킹 등의 트리에서 먼저 축적된 패치로 구성된다. 이 리포지토리 체인은 임의로 길 수 있지만 거의 두세 개의 링크를 넘지 않는다. 체인의 각 메인테이너가 하위 레벨 트리를 관리하는 사람을 신뢰하기 때문에 이 프로세스를 신뢰의 체인(chain of trust) 이라고 한다.
이런 시스템에서 패치를 커널에 넣는 것은 올바른 메인테이너를 찾는 것에 달려 있습니다. 패치를 linus 에게 직접 보내는 것은 일반적으로 올바른 방법이 아니다.
3. next tree
서브 시스템 체인을 따라 패치가 메인라인으로 인도되지만 여기에는 문제가 있다.
서로 다른 서브 시스템 트리의 변경 사항을 병합하는 과정에서 충돌이 발생할 수 있지 않을까?
병합 과정에서 충돌이 발생할 수 있기에, 누군가는 다음 merge window 를 위해 준비 중인 모든 패치를 보고 싶어할 수 있다. 예를 들어, 핵심 커널 함수 프로토타입을 변경하는 패치는 해당 함수의 이전 형식을 사용하는 다른 패치와 충돌한다. 검토자와 테스터는 모든 변경 사항이 mainline 커널에 적용되기 전에 통합된 변경 사항을 확인하길 원하다. 관심을 가지는 모든 서브 시스템 트리에서 변경 사항을 직접 가져올 수도 있지만, 이는 오류가 발생하기 쉬운 작업이다.
이러한 문제에 대한 답은 -next 트리이다. 여기서는 테스트 및 검토를 위해 서브 시스템 트리의 패치가 모인다. 다음 사이클(릴리즈)을 위한 패치 병합 트리는 Stephen Rothwell 이 관리하는 linux-next 이다. linux-next 트리는 다음 merge window 가 닫힌 후의 mainline 에 대한 스냅샷이다. 따라서, merge window 기간 동안 병합된 모든 패치는 merge window 가 열리기 전에 linux-next 에 이미 포함되어 있어야 한다. Linux-next 트리의 병합이 이뤄지면 linux-kernel 과 linux-next 의 메일링 리스트에 이를 알린다.
4. staging tree
커널 소스 트리에는 drivers/staging/ 디렉토리가 있는데, 여기에는 커널 트리에 추가될 드라이버나 파일 시스템이 있다. 드라이버나 파일 시스템이 mainline 으로 가기 위한 더 많은 작업이 필요한 동안은 drivers/staging 에 남게 된다. 작업이 완료되면 커널 내의 적절한 디렉토리로 이동된다.
Greg Kroah-Hartman 은 현재 staging tree 의 메인테이너이다. 아직 작업이 필요한 드라이버는 그에게 전송되며, 각 드라이버는 drivers/staging/ 에 자체적인 하위 디렉토리를 갖는다. 드라이버 소스 파일과 함께 디렉토리에 TODO 파일 도 있어야 한다. TODO 파일 에는 드라이버가 커널에 제대로 수용되기 위해 필요한 작업과 패치에 대해 참조해야 하는 사람들의 목록이 적혀있다. staging 에 올라간 드라이버는 최소한 적절하게 컴파일될 수 있어야 한다.
staging 은 새로운 드라이버를 mainline 에 도입하는 비교적 쉬운 방법이 될 수 있으며, 운이 좋으면 다른 개발자의 주목을 받아 빠르게 개선될 것이다. 하지만 staging 에 진입한다고 mainline 으로 가는 것은 아니다. staging 에서 정기적으로 개선되지 않는 코드는 결국 제거된다. 또한 배포자는 staging 의 드라이버를 활성화하는 것을 비교적 꺼리는 경향이 있다. 따라서 staging 은 기껏해야 적절한 mainline 의 드라이버가 되기 위한 중간 기착지일 뿐입니다.
출처
https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html#netdev-faq
https://www.kernel.org/doc/man-pages/linux-next.html
https://www.kernel.org/doc/html/latest/process/2.Process.html#how-patches-get-into-the-kernel
https://en.wikipedia.org/wiki/Mm_tree
https://slideplayer.com/slide/6202889/
