Linux Kernel 의 버전관리

이동표(구름과비) 2014.06.26 16:47 조회 수 : 7456 추천:1

명색이 커널 코드를 분석한다고 덤벼든 개발자(저 말입니다..;;;)가 Linux Kernel 의 버전관리가
어떻게 이루어지는지를 정확히 모르고 있었네요.

mainline 과 rc 버전 stable 버전 등이 Community 에서 어떻게 관리되는지가 갑자기 궁금해져서

Linux Kernel 의 개발자 Community 에 올라온 Guide 문서를 좀 읽어보고 블로그에 정리한 내용을 여기에 옮깁니다.


물론 iamroot 의 대부분 회원들은 이미 알고 계신 내용이겠지만, 저 같이 뒷북치기 좋아하는 분들에게 

혹시 도움이 되실까 하여 공유합니다. ^^;;;
혹시라도 제가 영문해석을 잘못하여 사실과 다르게 이해한 것도 있을 수 있으니 그런 부분이 있다면 지적바랍니다.


==================

버전관리가 어떻게 이루어지는지를 이해하면 Linux Kernel 의 개발 Process 를 어느정도 이해할 수 있기 때문에 

Kernel 을 공부하는 개발자의 상식으로라도 알아두는 것이 좋겠다.

Linux Kernel 개발 process 에 참여하고 싶거나 관심이 있는 개발자라면 아래의 Link 를 유심히 읽어볼 것을 권장한다. 
개발자들이 Linux Kernel 의 개발 Process 를 반드시 이해하고 참여하도록 유도하기 위한 문서이다. 
이러한 Process 를 이해하지 못한 상태에서 참여한 개발자들이 Community 의 분위기를 해치거나 악영향을 줄 

가능성이 있기 때문에 사전에 이에 대한 Guide 를 제시한 셈이다.


http://www.linuxfoundation.org/content/how-participate-linux-community-0


오늘 나는 이 문서의 내용중에서 특히 기본적으로 알고 있어야할 Linux Kernel 의 Versioning 에 관해 요약해보려고 한다.
Linux Kernel 의 버전 관리가 이전에 비해서 좀더 복잡해진 가운데, 릴리즈 주기가 약 3 개월 단위로 짧아진 것은 

버전관리 Process 가 그만큼 효율적으로 잘 정립되어 있기 때문이 아닌가 싶다.
참고로, 포스팅을 하고 있는 2014/06/26 일 현재 Linux Kernel 의 최신 Stable 버전은 3.15.1 이며, 2.6.x 버전에서 

3.x 버전으로 넘어온 것은 2011 년이다. (이는 Linux Kernel 의 Open 20 주년을 기념하기 위해 버전을 올린 것이라고 한다.)


https://www.kernel.org/#sthash.knwFcmhG.dpuf 에 방문해보면 아래와 같이 몇 가지 종류의 

릴리즈 버전들이 존재하는 것을 확인할 수 있다.


272CE74E53AB92682BDD63


위의 버전들이 무엇인가를 이해하려면 아래의 4 가지 종류의 릴리즈 버전의 생성 Process 를 알고 있어야 한다.

    • Mainline
    • rc (개발버전)
    • Stable
    • Longterm

Mainline 은 그 유명한 리누스 토발즈가 관리하는 개발 버전의 Main Tree 이다. 

Git 을 통해 관리되는데 SVN 을 기준으로 말하면 Linux Kernel 코드의 Trunk 라고 할 수 있다.
즉, 모든 Linux Kernel 버전 Tree 의 기준이자 시발점이 된다.

Mainline 은 버전이 3.X 처럼 두 자리가 된다.

리누스 토발즈가 약 2 주 동안 Merge Window 를 열어놓으면 개발자 Community 에서 Accept 되는 모든 변경 사항들이 

Mainline 에 Merge 된다. 
Merge Window 라는 것은 Community 의 개발자들이 Maintainer(코드 관리권한을 부여받은 Community 개발자)를 통해 

Linux Kernel Mainline 에 새로운 변경들을 Merge 할 수 있는 기간이 시작되었다는 것을 의미하는 용어이다.
즉, 리누스 토발즈가 Merge Window 를 Open 했다고 공표한 기간에만 Mainline 에 변경들이 Maintainer 를 통해 Merge 될 수 있다. Merge Window 가 닫히면 버그가 아닌 이상 더 이상의 변경들은 Merge 될 수 없다.


리누스 토발즈가 Merge Window 의 종료를 선언하면 그 때의 Linux Kernel 버전이 곧 rc1 이 된다.
만약 Mainline 이 3.12 였다고 가정하고, 그 이전의 최종 Stable 버전이 3.12.20 이었다면, 이번 Merge Window 가 

닫힌 직후의 버전은 곧  3.12.21-rc1 이 되는 것이다.
(위의 그림은 3.15 에서 3.16 으로 넘어가는 단계라서 3.16-rc2 로 한 것 같다.)
이는 3.12.21 이라는 Stable 버전을 만들기 위한 첫번째 개발 버전이라는 의미라고 보면 되겠다.

Merge Window 가 닫혔다고 곧바로 Stable 버전이 되는 것은 아니고, 6~10 주 동안은 Bug Fix 등과 같은 변경 사항이 

Mainline 에 적용될 수 있다.
이러한 변경이 적용되면서 rc2, rc3 와 같이 rc 버전이 올라간다.
보통은 이 기간에 Bug Fix 만이 허용되지만, 예외적으로 기존에 지원하지 않던 H/W 를 지원하는 Driver 를 추가하거나하는 

것들은 허용될 수 있다. 이는 기존의 기능들에 해를 끼쳐 퇴화시키는 일(regression)이 없기 때문이다.


보통 r6 ~ r9 정도 되면 해당 개발버전이 어느정도 안정화되었다고 판단하고 3.12.21 이라는 버전으로 Stable 버전을 릴리즈한다.

Stable 버전이 릴리즈되면 이 때부터는 리누스 토발즈가 관리하는 것이 아니라 별도의 Stable Team 에서 관리를 맡게 된다.
Stable Team 은 3.12.21.5 와 같이 4 자리까지 사용하여 3.12.21 Stable 버전에 대한 Update 를 관리해나갈 수 있다. 

이렇게 Update 의 대상이 되는 것은 심각한 Bug 이면서 Mainline 에 이미 적용된 것들에만 해당된다.

보통 6 개월 정도 이런 update 릴리즈과정을 거친 후, 그 이후부터는 유지보수가 해당 Kernel 버전을 이용하는 

Distributor 의 책임이 된다.


앞에서 리누스 토발즈가 마치 Mainline 에 대한 Merge 들을 모두 관리하는 것처럼 언급했는데, 사실 이는 불가능한 일이다. 

엄청나게 많은 변경량을 혼자 확인하고 관리하는 것이 가능하겠는가 ?
이 때문에 Linux Kernel 의 코드 관리는 마치 군대계급처럼 철저하게 Tree 형태의 관리 계급이에 의해 이루어진다.
Network, Memory Management, File System 등 subsystem 관리자(Maintainer)들이 자신의 계급(Level)에 맞는 

범위를 관리하게 된다. 그리고, 이러한 관리는 철저하게 신뢰에 바탕을 두고 이루어진다.


Longterm 버전은 말 그대로 이전 버전들 중에서 오랜 기간동안 계속해서 유지관리가 될 버전들을 말한다. 

longterm 버전을 따로 관리하지 않으면 개발자들이 다양한 stable 버전들에 대해 수정하고자 하는 욕구가 사그라들 것이 분명하다.
그래서, 특정 버전을 longterm 버전으로 지정해두고 이에 대한 관리가 오랜기간 지속될 수 있도록 한 것 같다.

Linux Kernel 의 코드 관리에 있어서 Maintainer 의 역할은 절대적이라고 할 수 있다. 각자 자신이 맡은 

영역에 대한 전문가여야하는 것은 물론이고, 코드의 Merge 에 대해서 무한한 열정과 책임을 가진 사람이어야하지 않을까 싶다.


Kernel 개발자들은 이러한 Maintainer 의 존재를 알고 있어야 함은 당연하고, 혹시라도 특정 Kernel 버전의 

특정 부분에 대한 질의나 문제점을 찾았을 경우에는 전체 Linux Kernel Mailing List 에 포스팅을 할 것이 아니라 , 

어떤 방법으로든 해당 Maintainer 를 찾거나 그 분야의 Mailing List 에 한정하여 포스팅을 하는 것이 좋을 것이다.

번호 제목 글쓴이 날짜 조회 수
공지 [공지] IAMROOT 19차 커널 스터디 오리엔테이션 (zoom 접속 안내) [5] 문c(문영일) 2022.05.07 915
공지 [공지] IAMROOT 18차 커널 스터디 오리엔테이션 안내 [마감] [2] 문c(문영일) 2021.05.17 1259
공지 커널 스터디를 위한 문c 가이드입니다. [10] 문c(문영일) 2021.04.27 6610
1077 초대형 블록버스터 라스트 갓 파더 [1] 배상경 2010.12.01 7456
» Linux Kernel 의 버전관리 [4] 이동표(구름과비) 2014.06.26 7456
1075 혹시 이론 물리학 관심 있으신분 계신가요? [3] 백창우 2008.03.21 7417
1074 "anfl" KLDP회원님을 찾습니다. michael 2008.11.26 7384
1073 GCC 2차 세미나 많이들 신청해주세요. [1] 백창우 2009.04.30 7376
1072 건강들 챙기시기 바랍니다. 안타까운글이 올라와서요.. [6] 이상철 2010.03.19 7367
1071 반갑습니다. 가입인사 드립니다 [2] 문유성 2011.08.31 7354
1070 [반공지] 소스 분석하실때 encoding을 utf-8로 통일하십시요. 백창우 2011.08.02 7349
1069 커널 최적화 기법 백창우 2011.10.12 7325
1068 [커널 15차 A팀] 21주차(2018-09-15) 스터디 노트 코딩의노예 2018.09.16 7323
1067 GCC 세미나 장소 공지 [1] 원민수 2009.05.04 7321
1066 러셀 킹 한테 답장이 왔는데... [3] 홍문화 2011.08.22 7293
1065 노서영 박사님 발표자료 입니다. [3] file 백창우 2012.04.08 7276
1064 GCC 세미나 장소 공지 원민수 2009.04.02 7269
1063 [모집] 국산 슈퍼컴 ‘천둥’을 활용한 병렬 프로그래밍 전문가 과정 교육생 모집 file 나정호 2013.04.16 7264
1062 Intel VLIW Processor & Compiler 백창우 2008.01.20 7255
1061 control키하고 caps lock키 변경하는 방법이라네요~ file 이상철 2008.12.02 7227
1060 질문이요. [1] 신재호 2010.11.23 7223
1059 노트북 쓰시는 분들은 어떤 모델 쓰시나요? [14] 이승우 2011.08.11 7215
1058 multi-core rtos 조건 백창우 2012.08.21 7192
XE Login