Commit | Line | Data |
---|---|---|
dda8cc86 MK |
1 | NOTE: |
2 | This is a version of Documentation/HOWTO translated into korean | |
3 | This document is maintained by minchan Kim < minchan.kim@gmail.com> | |
4 | If you find any difference between this document and the original file or | |
5 | a problem with the translation, please contact the maintainer of this file. | |
6 | ||
7 | Please also note that the purpose of this file is to be easier to | |
8 | read for non English (read: korean) speakers and is not intended as | |
9 | a fork. So if you have any comments or updates for this file please | |
10 | try to update the original English file first. | |
11 | ||
12 | ================================== | |
13 | 이 문서는 | |
14 | Documentation/HOWTO | |
15 | 의 한글 번역입니다. | |
16 | ||
17 | 역자: 김민찬 <minchan.kim@gmail.com > | |
18 | 감수: 이제이미 <jamee.lee@samsung.com> | |
19 | ================================== | |
20 | ||
21 | 어떻게 리눅스 커널 개발을 하는가 | |
22 | --------------------------------- | |
23 | ||
24 | 이 문서는 커널 개발에 있어 가장 중요한 문서이다. 이 문서는 | |
25 | 리눅스 커널 개발자가 되는 법과 리눅스 커널 개발 커뮤니티와 일하는 | |
26 | 법을 담고있다. 커널 프로그래밍의기술적인 측면과 관련된 내용들은 | |
27 | 포함하지 않으려고 하였지만 올바으로 여러분을 안내하는 데 도움이 | |
28 | 될 것이다. | |
29 | ||
30 | 이 문서에서 오래된 것을 발견하면 문서의 아래쪽에 나열된 메인트너에게 | |
31 | 패치를 보내달라. | |
32 | ||
33 | ||
34 | 소개 | |
35 | ---- | |
36 | ||
37 | 자, 여러분은 리눅스 커널 개발자가 되는 법을 배우고 싶은가? 아니면 | |
38 | 상사로부터"이 장치를 위한 리눅스 드라이버를 작성하시오"라는 말을 | |
39 | 들었는가? 이 문서는 여러분이 겪게 될 과정과 커뮤니티와 일하는 법을 | |
40 | 조언하여 여러분의 목적을 달성하기 위해 필요한 것 모두를 알려주는 | |
41 | 것이다. | |
42 | ||
43 | 커널은 대부분은 C로 작성되었어고 몇몇 아키텍쳐의 의존적인 부분은 | |
44 | 어셈블리로 작성되었다. 커널 개발을 위해 C를 잘 이해하고 있어야 한다. | |
45 | 여러분이 특정 아키텍쳐의 low-level 개발을 할 것이 아니라면 | |
46 | 어셈블리(특정 아키텍쳐)는 잘 알아야 할 필요는 없다. | |
47 | 다음의 참고서적들은 기본에 충실한 C 교육이나 수년간의 경험에 견주지는 | |
48 | 못하지만 적어도 참고 용도로는 좋을 것이다 | |
49 | - "The C Programming Language" by Kernighan and Ritchie [Prentice Hall] | |
50 | - "Practical C Programming" by Steve Oualline [O'Reilly] | |
51 | - "C: A Reference Manual" by Harbison and Steele [Prentice Hall] | |
52 | ||
53 | 커널은 GNU C와 GNU 툴체인을 사용하여 작성되었다. 이 툴들은 ISO C89 표준을 | |
54 | 따르는 반면 표준에 있지 않은 많은 확장기능도 가지고 있다. 커널은 표준 C | |
55 | 라이브러리와는 관계없이 freestanding C 환경이어서 C 표준의 일부는 | |
56 | 지원되지 않는다. 임의의 long long 나누기나 floating point는 지원되지 않는다. | |
57 | 때론 이런 이유로 커널이 그런 확장 기능을 가진 툴체인을 가지고 만들어졌다는 | |
58 | 것이 이해하기 어려울 수도 있고 게다가 불행하게도 그런 것을 정확하게 설명하는 | |
59 | 어떤 참고문서도 있지 않다. 정보를 얻기 위해서는 gcc info (`info gcc`)페이지를 | |
60 | 살펴보라. | |
61 | ||
62 | 여러분은 기존의 개발 커뮤니티와 일하는 법을 배우려고 하고 있다는 것을 | |
63 | 기억하라. 코딩, 스타일, 절차에 관한 훌륭한 표준을 가진 사람들이 모인 | |
64 | 다양한 그룹이 있다. 이 표준들은 오랜동안 크고 지역적으로 분산된 팀들에 | |
65 | 의해 가장 좋은 방법으로 일하기위하여 찾은 것을 기초로 만들어져왔다. | |
66 | 그 표준들은 문서화가 잘 되어 있기 때문에 가능한한 미리 많은 표준들에 | |
67 | 관하여 배우려고 시도하라. 다른 사람들은 여러분이나 여러분의 회사가 | |
68 | 일하는 방식에 적응하는 것을 원하지는 않는다. | |
69 | ||
70 | ||
71 | 법적 문제 | |
72 | --------- | |
73 | ||
74 | 리눅스 커널 소스 코드는 GPL로 배포(release)되었다. 소스트리의 메인 | |
75 | 디렉토리에 있는 라이센스에 관하여 상세하게 쓰여 있는 COPYING이라는 | |
76 | 파일을 봐라.여러분이 라이센스에 관한 더 깊은 문제를 가지고 있다면 | |
77 | 리눅스 커널 메일링 리스트에 묻지말고 변호사와 연락하라. 메일링 | |
78 | 리스트들에 있는 사람들은 변호사가 아니기 때문에 법적 문제에 관하여 | |
79 | 그들의 말에 의지해서는 안된다. | |
80 | ||
81 | GPL에 관한 잦은 질문들과 답변들은 다음을 참조하라. | |
82 | http://www.gnu.org/licenses/gpl-faq.html | |
83 | ||
84 | ||
85 | 문서 | |
86 | ---- | |
87 | ||
88 | 리눅스 커널 소스 트리는 커널 커뮤니티와 일하는 법을 배우기 위한 많은 | |
89 | 귀중한 문서들을 가지고 있다. 새로운 기능들이 커널에 들어가게 될 때, | |
90 | 그 기능을 어떻게 사용하는지에 관한 설명을 위하여 새로운 문서 파일을 | |
91 | 추가하는 것을 권장한다. 커널이 유저스페이스로 노출하는 인터페이스를 | |
92 | 변경하게 되면 변경을 설명하는 메뉴얼 페이지들에 대한 패치나 정보를 | |
93 | mtk-manpages@gmx.net의 메인트너에게 보낼 것을 권장한다. | |
94 | ||
95 | 다음은 커널 소스 트리에 있는 읽어야 할 파일들의 리스트이다. | |
96 | README | |
97 | 이 파일은 리눅스 커널에 관하여 간단한 배경 설명과 커널을 설정하고 | |
98 | 빌드하기 위해 필요한 것을 설명한다. 커널에 입문하는 사람들은 여기서 | |
99 | 시작해야 한다. | |
100 | ||
101 | Documentation/Changes | |
102 | 이 파일은 커널을 성공적으로 빌드하고 실행시키기 위해 필요한 다양한 | |
103 | 소프트웨어 패키지들의 최소 버젼을 나열한다. | |
104 | ||
105 | Documentation/CodingStyle | |
106 | 이 문서는 리눅스 커널 코딩 스타일과 그렇게 한 몇몇 이유를 설명한다. | |
107 | 모든 새로운 코드는 이 문서에 가이드라인들을 따라야 한다. 대부분의 | |
108 | 메인트너들은 이 규칙을 따르는 패치들만을 받아들일 것이고 많은 사람들이 | |
109 | 그 패치가 올바른 스타일일 경우만 코드를 검토할 것이다. | |
110 | ||
111 | Documentation/SubmittingPatches | |
112 | Documentation/SubmittingDrivers | |
113 | 이 파일들은 성공적으로 패치를 만들고 보내는 법을 다음의 내용들로 | |
114 | 굉장히 상세히 설명하고 있다(그러나 다음으로 한정되진 않는다). | |
115 | - Email 내용들 | |
116 | - Email 양식 | |
117 | - 그것을 누구에게 보낼지 | |
118 | 이러한 규칙들을 따르는 것이 성공을 보장하진 않는다(왜냐하면 모든 | |
119 | 패치들은 내용과 스타일에 관하여 면밀히 검토되기 때문이다). | |
120 | 그러나 규칙을 따르지 않는다면 거의 성공하지도 못할 것이다. | |
121 | ||
122 | 올바른 패치들을 만드는 법에 관한 훌륭한 다른 문서들이 있다. | |
123 | "The Perfect Patch" | |
124 | http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt | |
125 | "Linux kernel patch submission format" | |
126 | http://linux.yyz.us/patch-format.html | |
127 | ||
128 | Documentation/stable_api_nonsense.txt | |
129 | 이 문서는 의도적으로 커널이 변하지 않는 API를 갖지 않도록 결정한 | |
130 | 이유를 설명하며 다음과 같은 것들을 포함한다. | |
131 | - 서브시스템 shim-layer(호환성을 위해?) | |
132 | - 운영 체제들 간의 드라이버 이식성 | |
133 | - 커널 소스 트리내에 빠른 변화를 늦추는 것(또는 빠른 변화를 막는 것) | |
134 | 이 문서는 리눅스 개발 철학을 이해하는데 필수적이며 다른 운영체제에서 | |
135 | 리눅스로 옮겨오는 사람들에게는 매우 중요하다. | |
136 | ||
137 | ||
138 | Documentation/SecurityBugs | |
139 | 여러분들이 리눅스 커널의 보안 문제를 발견했다고 생각한다면 이 문서에 | |
140 | 나온 단계에 따라서 커널 개발자들에게 알리고 그 문제를 해결할 수 있도록 | |
141 | 도와 달라. | |
142 | ||
143 | Documentation/ManagementStyle | |
144 | 이 문서는 리눅스 커널 메인트너들이 어떻게 그들의 방법론의 정신을 | |
145 | 어떻게 공유하고 운영하는지를 설명한다. 이것은 커널 개발에 입문하는 | |
146 | 모든 사람들(또는 커널 개발에 작은 호기심이라도 있는 사람들)이 | |
147 | 읽어야 할 중요한 문서이다. 왜냐하면 이 문서는 커널 메인트너들의 | |
148 | 독특한 행동에 관하여 흔히 있는 오해들과 혼란들을 해소하고 있기 | |
149 | 때문이다. | |
150 | ||
151 | Documentation/stable_kernel_rules.txt | |
152 | 이 문서는 안정적인 커널 배포가 이루어지는 규칙을 설명하고 있으며 | |
153 | 여러분들이 이러한 배포들 중 하나에 변경을 하길 원한다면 | |
154 | 무엇을 해야 하는지를 설명한다. | |
155 | ||
156 | Documentation/kernel-docs.txt | |
157 | 커널 개발에 관계된 외부 문서의 리스트이다. 커널 내의 포함된 문서들 | |
158 | 중에 여러분이 찾고 싶은 문서를 발견하지 못할 경우 이 리스트를 | |
159 | 살펴보라. | |
160 | ||
161 | Documentation/applying-patches.txt | |
162 | 패치가 무엇이며 그것을 커널의 다른 개발 브랜치들에 어떻게 | |
163 | 적용하는지에 관하여 자세히 설명 하고 있는 좋은 입문서이다. | |
164 | ||
165 | 커널은 소스 코드 그 자체에서 자동적으로 만들어질 수 있는 많은 문서들을 | |
166 | 가지고 있다. 이것은 커널 내의 API에 대한 모든 설명, 그리고 락킹을 | |
167 | 올바르게 처리하는 법에 관한 규칙을 포함하고 있다. 이 문서는 | |
168 | Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, HTML, | |
169 | 그리고 man 페이지들로 다음과 같이 실행하여 만들어 진다. | |
170 | make pdfdocs | |
171 | make psdocs | |
172 | make htmldocs | |
173 | make mandocs | |
174 | 각각의 명령을 메인 커널 소스 디렉토리로부터 실행한다. | |
175 | ||
176 | ||
177 | 커널 개발자가 되는 것 | |
178 | --------------------- | |
179 | ||
180 | 여러분이 리눅스 커널 개발에 관하여 아무것도 모른다면 Linux KernelNewbies | |
181 | 프로젝트를 봐야 한다. | |
182 | http://kernelnewbies.org | |
183 | 그곳은 거의 모든 종류의 기본적인 커널 개발 질문들(질문하기 전에 먼저 | |
184 | 아카이브를 찾아봐라. 과거에 이미 답변되었을 수도 있다)을 할수있는 도움이 | |
185 | 될만한 메일링 리스트가 있다. 또한 실시간으로 질문 할수 있는 IRC 채널도 | |
186 | 가지고 있으며 리눅스 커널 개발을 배우는 데 유용한 문서들을 보유하고 있다. | |
187 | ||
188 | 웹사이트는 코드구성, 서브시스템들, 그리고 현재 프로젝트들 | |
189 | (트리 내, 외부에 존재하는)에 관한 기본적인 정보들을 가지고 있다. 또한 | |
190 | 그곳은 커널 컴파일이나 패치를 하는 법과 같은 기본적인 것들을 설명한다. | |
191 | ||
192 | 여러분이 어디서 시작해야 할진 모르지만 커널 개발 커뮤니티에 참여할 수 | |
193 | 있는 일들을 찾길 원한다면 리눅스 커널 Janitor 프로젝트를 살펴봐라. | |
194 | http://janitor.kernelnewbies.org/ | |
195 | 그곳은 시작하기에 아주 딱 좋은 곳이다. 그곳은 리눅스 커널 소스 트리내에 | |
196 | 간단히 정리되고 수정될 수 있는 문제들에 관하여 설명한다. 여러분은 이 | |
197 | 프로젝트를 대표하는 개발자들과 일하면서 자신의 패치를 리눅스 커널 트리에 | |
198 | 반영하기 위한 기본적인 것들을 배우게 될것이며 여러분이 아직 아이디어를 | |
199 | 가지고 있지 않다면 다음에 무엇을 해야할지에 관한 방향을 배울 수 있을 | |
200 | 것이다. | |
201 | ||
202 | 여러분들이 이미 커널 트리에 반영하길 원하는 코드 묶음을 가지고 있지만 | |
203 | 올바른 포맷으로 포장하는데 도움이 필요하다면 그러한 문제를 돕기 위해 | |
204 | 만들어진 kernel-mentors 프로젝트가 있다. 그곳은 메일링 리스트이며 | |
205 | 다음에서 참조할 수 있다. | |
206 | http://selenic.com/mailman/listinfo/kernel-mentors | |
207 | ||
208 | 리눅스 커널 코드에 실제 변경을 하기 전에 반드시 그 코드가 어떻게 | |
209 | 동작하는지 이해하고 있어야 한다. 코드를 분석하기 위하여 특정한 툴의 | |
210 | 도움을 빌려서라도 코드를 직접 읽는 것보다 좋은 것은 없다(대부분의 | |
211 | 자잘한 부분들은 잘 코멘트되어 있다). 그런 툴들 중에 특히 추천할만한 | |
212 | 것은 Linux Cross-Reference project이며 그것은 자기 참조 방식이며 | |
213 | 소스코드를 인덱스된 웹 페이지들의 형태로 보여준다. 최신의 멋진 커널 | |
214 | 코드 저장소는 다음을 통하여 참조할 수 있다. | |
215 | http://sosdg.org/~coywolf/lxr/ | |
216 | ||
217 | ||
218 | 개발 프로세스 | |
219 | ------------- | |
220 | ||
221 | 리눅스 커널 개발 프로세스는 현재 몇몇 다른 메인 커널 "브랜치들"과 | |
222 | 서브시스템에 특화된 커널 브랜치들로 구성된다. 몇몇 다른 메인 | |
223 | 브랜치들은 다음과 같다. | |
224 | - main 2.6.x 커널 트리 | |
225 | - 2.6.x.y - 안정된 커널 트리 | |
226 | - 2.6.x -git 커널 패치들 | |
227 | - 2.6.x -mm 커널 패치들 | |
228 | - 서브시스템을 위한 커널 트리들과 패치들 | |
229 | ||
230 | 2.6.x 커널 트리 | |
231 | --------------- | |
232 | ||
233 | 2.6.x 커널들은 Linux Torvalds가 관리하며 kernel.org의 pub/linux/kernel/v2.6/ | |
234 | 디렉토리에서 참조될 수 있다.개발 프로세스는 다음과 같다. | |
235 | - 새로운 커널이 배포되자마자 2주의 시간이 주어진다. 이 기간동은 | |
236 | 메인트너들은 큰 diff들을 Linus에게 제출할 수 있다. 대개 이 패치들은 | |
237 | 몇 주 동안 -mm 커널내에 이미 있었던 것들이다. 큰 변경들을 제출하는 데 | |
238 | 선호되는 방법은 git(커널의 소스 관리 툴, 더 많은 정보들은 http://git.or.cz/ | |
239 | 에서 참조할 수 있다)를 사용하는 것이지만 순수한 패치파일의 형식으로 보내도 | |
240 | 것도 무관하다. | |
241 | - 2주 후에 -rc1 커널이 배포되며 지금부터는 전체 커널의 안정성에 영향을 | |
242 | 미칠수 있는 새로운 기능들을 포함하지 않는 패치들만을 추가될 수 있다. | |
243 | 완전히 새로운 드라이버(혹은 파일시스템)는 -rc1 이후에만 받아들여진다는 | |
244 | 것을 기억해라. 왜냐하면 변경이 자체내에서만 발생하고 추가된 코드가 | |
245 | 드라이버 외부의 다른 부분에는 영향을 주지 않으므로 그런 변경은 | |
246 | 퇴보(regression)를 일으킬 만한 위험을 가지고 있지 않기 때문이다. -rc1이 | |
247 | 배포된 이후에 git를 사용하여 패치들을 Linus에게 보낼수 있지만 패치들은 | |
248 | 공식적인 메일링 리스트로 보내서 검토를 받을 필요가 있다. | |
249 | - 새로운 -rc는 Linus는 현재 git tree가 테스트 하기에 충분히 안정된 상태에 | |
250 | 있다고 판단될 때마다 배포된다. 목표는 새로운 -rc 커널을 매주 배포하는 | |
251 | 것이다. | |
252 | - 이러한 프로세스는 커널이 "준비"되었다고 여겨질때까지 계속된다. | |
253 | 프로세스는 대체로 6주간 지속된다. | |
254 | - 각 -rc 배포에 있는 알려진 퇴보의 목록들은 다음 URI에 남겨진다. | |
255 | http://kernelnewbies.org/known_regressions | |
256 | ||
257 | 커널 배포에 있어서 언급할만한 가치가 있는 리눅스 커널 메일링 리스트의 | |
258 | Andrew Morton의 글이 있다. | |
259 | "커널이 언제 배포될지는 아무로 모른다. 왜냐하면 배포는 알려진 | |
260 | 버그의 상황에 따라 배포되는 것이지 미리정해 놓은 시간에 따라 | |
261 | 배포되는 것은 아니기 때문이다." | |
262 | ||
263 | 2.6.x.y - 안정 커널 트리 | |
264 | ------------------------ | |
265 | ||
266 | 4 자리 숫자로 이루어진 버젼의 커널들은 -stable 커널들이다. 그것들은 2.6.x | |
267 | 커널에서 발견된 큰 퇴보들이나 보안 문제들 중 비교적 작고 중요한 수정들을 | |
268 | 포함한다. | |
269 | ||
270 | 이것은 가장 최근의 안정적인 커널을 원하는 사용자에게 추천되는 브랜치이며, | |
271 | 개발/실험적 버젼을 테스트하는 것을 돕는데는 별로 관심이 없다. | |
272 | ||
273 | 어떤 2.6.x.y 커널도 사용가능하지 않다면 그때는 가장 높은 숫자의 2.6.x | |
274 | 커널이 현재의 안정 커널이다. | |
275 | ||
276 | 2.6.x.y는 "stable" 팀<stable@kernel.org>에 의해 관리되며 거의 매번 격주로 | |
277 | 배포된다. | |
278 | ||
279 | 커널 트리 문서들 내에 Documentation/stable_kernel_rules.txt 파일은 어떤 | |
280 | 종류의 변경들이 -stable 트리로 들어왔는지와 배포 프로세스가 어떻게 | |
281 | 진행되는지를 설명한다. | |
282 | ||
283 | ||
284 | 2.6.x -git 패치들 | |
285 | ------------------ | |
286 | git 저장소(그러므로 -git이라는 이름이 붙음)에는 날마다 관리되는 Linus의 | |
287 | 커널 트리의 snapshot 들이 있다. 이 패치들은 일반적으로 날마다 배포되며 | |
288 | Linus의 트리의 현재 상태를 나타낸다. 이 패치들은 정상적인지 조금도 | |
289 | 살펴보지 않고 자동적으로 생성된 것이므로 -rc 커널들 보다도 더 실험적이다. | |
290 | ||
291 | 2.6.x -mm 커널 패치들 | |
292 | --------------------- | |
293 | Andrew Morton에 의해 배포된 실험적인 커널 패치들이다. Andrew는 모든 다른 | |
294 | 서브시스템 커널 트리와 패치들을 가져와서 리눅스 커널 메일링 리스트로 | |
295 | 온 많은 패치들과 한데 묶는다. 이 트리는 새로운 기능들과 패치들을 위한 | |
296 | 장소를 제공하는 역할을 한다. 하나의 패치가 -mm에 한동안 있으면서 그 가치가 | |
297 | 증명되게 되면 Andrew나 서브시스템 메인트너는 그것을 메인라인에 포함시키기 | |
298 | 위하여 Linus에게 보낸다. | |
299 | ||
300 | 커널 트리에 포함하고 싶은 모든 새로운 패치들은 Linus에게 보내지기 전에 | |
301 | -mm 트리에서 테스트를 하는 것을 적극 추천한다. | |
302 | ||
303 | 이 커널들은 안정되게 사용할 시스템에서에 실행하는 것은 적합하지 않으며 | |
304 | 다른 브랜치들의 어떤 것들보다 위험하다. | |
305 | ||
306 | 여러분이 커널 개발 프로세스를 돕길 원한다면 이 커널 배포들을 사용하고 | |
307 | 테스트한 후 어떤 문제를 발견하거나 또는 모든 것이 잘 동작한다면 리눅스 | |
308 | 커널 메일링 리스트로 피드백을 해달라. | |
309 | ||
310 | 이 커널들은 일반적으로 모든 다른 실험적인 패치들과 배포될 당시의 | |
311 | 사용가능한 메인라인 -git 커널들의 몇몇 변경을 포함한다. | |
312 | ||
313 | -mm 커널들은 정해진 일정대로 배포되지 않는다. 하지만 대개 몇몇 -mm 커널들은 | |
314 | 각 -rc 커널(1부터 3이 흔함) 사이에서 배포된다. | |
315 | ||
316 | 서브시스템 커널 트리들과 패치들 | |
317 | ------------------------------- | |
318 | 많은 다른 커널 서브시스템 개발자들은 커널의 다른 부분들에서 무슨 일이 | |
319 | 일어나고 있는지를 볼수 있도록 그들의 개발 트리를 공개한다. 이 트리들은 | |
320 | 위에서 설명하였던 것 처럼 -mm 커널 배포들로 합쳐진다. | |
321 | ||
322 | 다음은 활용가능한 커널 트리들을 나열한다. | |
323 | git trees: | |
324 | - Kbuild development tree, Sam Ravnborg < sam@ravnborg.org> | |
325 | git.kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git | |
326 | ||
327 | - ACPI development tree, Len Brown <len.brown@intel.com > | |
328 | git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git | |
329 | ||
330 | - Block development tree, Jens Axboe <axboe@suse.de> | |
331 | git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git | |
332 | ||
333 | - DRM development tree, Dave Airlie <airlied@linux.ie> | |
334 | git.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git | |
335 | ||
336 | - ia64 development tree, Tony Luck < tony.luck@intel.com> | |
337 | git.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git | |
338 | ||
339 | - infiniband, Roland Dreier <rolandd@cisco.com > | |
340 | git.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git | |
341 | ||
342 | - libata, Jeff Garzik <jgarzik@pobox.com> | |
343 | git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git | |
344 | ||
345 | - network drivers, Jeff Garzik <jgarzik@pobox.com> | |
346 | git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git | |
347 | ||
348 | - pcmcia, Dominik Brodowski < linux@dominikbrodowski.net> | |
349 | git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git | |
350 | ||
351 | - SCSI, James Bottomley < James.Bottomley@SteelEye.com> | |
352 | git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git | |
353 | ||
354 | quilt trees: | |
355 | - USB, PCI, Driver Core, and I2C, Greg Kroah-Hartman < gregkh@suse.de> | |
356 | kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/ | |
357 | - x86-64, partly i386, Andi Kleen < ak@suse.de> | |
358 | ftp.firstfloor.org:/pub/ak/x86_64/quilt/ | |
359 | ||
360 | 다른 커널 트리들은 http://kernel.org/git와 MAINTAINERS 파일에서 참조할 수 | |
361 | 있다. | |
362 | ||
363 | 버그 보고 | |
364 | --------- | |
365 | bugzilla.kernel.org는 리눅스 커널 개발자들이 커널의 버그를 추적하는 곳이다. | |
366 | 사용자들은 발견한 모든 버그들을 보고하기 위하여 이 툴을 사용할 것을 권장한다. | |
367 | kernel bugzilla를 사용하는 자세한 방법은 다음을 참조하라. | |
368 | http://test.kernel.org/bugzilla/faq.html | |
369 | ||
370 | 메인 커널 소스 디렉토리에 있는 REPORTING-BUGS 파일은 커널 버그일 것 같은 | |
371 | 것을 보고하는는 법에 관한 좋은 템플릿이고 문제를 추적하기 위해서 커널 | |
372 | 개발자들이 필요로 하는 정보가 무엇들인지를 상세히 설명하고 있다. | |
373 | ||
374 | ||
375 | 버그 리포트들의 관리 | |
376 | -------------------- | |
377 | ||
378 | 여러분의 해킹 기술을 연습하는 가장 좋은 방법 중의 하는 다른 사람들이 | |
379 | 보고한 버그들을 수정하는 것이다. 여러분은 커널을 더욱 안정화시키는데 | |
380 | 도움을 줄 뿐만이 아니라 실제있는 문제들을 수정하는 법을 배우게 되고 | |
381 | 그와 함께 여러분들의 기술은 향상될 것이며 다른 개발자들이 여러분의 | |
382 | 존재에 대해 알게 될 것이다. 버그를 수정하는 것은 개발자들 사이에서 | |
383 | 점수를 얻을 수 있는 가장 좋은 방법중의 하나이다. 왜냐하면 많은 사람들은 | |
384 | 다른 사람들의 버그들을 수정하기 위하여 시간을 낭비하지 않기 때문이다. | |
385 | ||
386 | 이미 보고된 버그 리포트들을 가지고 작업하기 위해서 http://bugzilla.kernelorg를 | |
387 | 참조하라. 여러분이 앞으로 생겨날 버그 리포트들의 조언자가 되길 원한다면 | |
388 | bugme-new 메일링 리스트나(새로운 버그 리포트들만이 이곳에서 메일로 전해진다) | |
389 | bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메일로 전해진다) | |
390 | 에 등록하면 된다. | |
391 | ||
392 | http://lists.osdl.org/mailman/listinfo/bugme-new | |
393 | http://lists.osdl.org/mailman/listinfo/bugme-janitors | |
394 | ||
395 | ||
396 | ||
397 | 메일링 리스트들 | |
398 | --------------- | |
399 | ||
400 | 위의 몇몇 문서들이 설명하였지만 핵심 커널 개발자들의 대다수는 | |
401 | 리눅스 커널 메일링 리스트에 참여하고 있다. 리스트에 등록하고 해지하는 | |
402 | 방법에 관한 자세한 사항은 다음에서 참조할 수 있다. | |
403 | http://vger.kernel.org/vger-lists.html#linux-kernel | |
404 | 웹상의 많은 다른 곳에도 메일링 리스트의 아카이브들이 있다. | |
405 | 이러한 아카이브들을 찾으려면 검색 엔진을 사용하라. 예를 들어: | |
406 | http://dir.gmane.org/gmane.linux.kernel | |
407 | 여러분이 새로운 문제에 관해 리스트에 올리기 전에 말하고 싶은 주제에 대한 | |
408 | 것을 아카이브에서 먼저 찾기를 강력히 권장한다. 이미 상세하게 토론된 많은 | |
409 | 것들이 메일링 리스트의 아카이브에 기록되어 있다. | |
410 | ||
411 | 각각의 커널 서브시스템들의 대부분은 자신들의 개발에 관한 노력들로 이루어진 | |
412 | 분리된 메일링 리스트를 따로 가지고 있다. 다른 그룹들이 무슨 리스트를 가지고 | |
413 | 있는지는 MAINTAINERS 파일을 참조하라. | |
414 | ||
415 | 많은 리스트들은 kernel.org에서 호스트되고 있다. 그 정보들은 다음에서 참조될 수 있다. | |
416 | http://vger.kernel.org/vger-lists.html | |
417 | ||
418 | 리스트들을 사용할 때는 올바른 예절을 따를 것을 유념해라. | |
419 | 대단하진 않지만 다음 URL은 리스트(혹은 모든 리스트)와 대화하는 몇몇 간단한 | |
420 | 가이드라인을 가지고 있다. | |
421 | http://www.albion.com/netiquette/ | |
422 | ||
423 | 여러 사람들이 여러분의 메일에 응답한다면 CC: 즉 수신 리스트는 꽤 커지게 | |
424 | 될 것이다. 아무 이유없이 CC에서 어떤 사람도 제거하거나 리스트 주소로만 | |
425 | 회신하지 마라. 메일을 보낸 사람으로서 하나를 받고 리스트로부터 또 | |
426 | 하나를 받아 두번 받는 것에 익숙하여 있으니 mail-header를 조작하려고 하지 | |
427 | 말아라. 사람들은 그런 것을 좋아하지 않을 것이다. | |
428 | ||
429 | 여러분의 회신의 문맥을 원래대로 유지해야 한다. 여러분들의 회신의 윗부분에 | |
430 | "John 커널해커는 작성했다...."를 유지하며 여러분들의 의견을 그 메일의 윗부분에 | |
431 | 작성하지 말고 각 인용한 단락들 사이에 넣어라. | |
432 | ||
433 | 여러분들이 패치들을 메일에 넣는다면 그것들은 Documentation/SubmittingPatches에 | |
434 | 나와있는데로 명백히(plain) 읽을 수 있는 텍스트여야 한다. 커널 개발자들은 | |
435 | 첨부파일이나 압축된 패치들을 원하지 않는다. 그들은 여러분들의 패치의 | |
436 | 각 라인 단위로 코멘트를 하길 원하며 압축하거나 첨부하지 않고 보내는 것이 | |
437 | 그렇게 할 수 있는 유일한 방법이다. 여러분들이 사용하는 메일 프로그램이 | |
438 | 스페이스나 탭 문자들을 조작하지 않는지 확인하라. 가장 좋은 첫 테스트는 | |
439 | 메일을 자신에게 보내보고 스스로 그 패치를 적용해보라. 그것이 동작하지 | |
440 | 않는다면 여러분의 메일 프로그램을 고치던가 제대로 동작하는 프로그램으로 | |
441 | 바꾸어라. | |
442 | ||
443 | 무엇보다도 메일링 리스트의 다른 구독자들에게 보여주려 한다는 것을 기억하라. | |
444 | ||
445 | ||
446 | 커뮤니티와 일하는 법 | |
447 | -------------------- | |
448 | ||
449 | 커널 커뮤니티의 목적은 가능한한 가장 좋은 커널을 제공하는 것이다. 여러분이 | |
450 | 받아들여질 패치를 제출하게 되면 그 패치의 기술적인 이점으로 검토될 것이다. | |
451 | 그럼 여러분들은 무엇을 기대하고 있어야 하는가? | |
452 | - 비판 | |
453 | - 의견 | |
454 | - 변경을 위한 요구 | |
455 | - 당위성을 위한 요구 | |
456 | - 고요 | |
457 | ||
458 | 기억하라. 이것들은 여러분의 패치가 커널로 들어가기 위한 과정이다. 여러분의 | |
459 | 패치들은 비판과 다른 의견을 받을 수 있고 그것들을 기술적인 레벨로 평가하고 | |
460 | 재작업하거나 또는 왜 수정하면 안되는지에 관하여 명료하고 간결한 이유를 | |
461 | 말할 수 있어야 한다. 여러분이 제출한 것에 어떤 응답도 있지 않다면 몇 일을 | |
462 | 기다려보고 다시 시도해라. 때론 너무 많은 메일들 속에 묻혀버리기도 한다. | |
463 | ||
464 | 여러분은 무엇을 해서는 안되는가? | |
465 | - 여러분의 패치가 아무 질문 없이 받아들여지기를 기대하는 것 | |
466 | - 방어적이 되는 것 | |
467 | - 의견을 무시하는 것 | |
468 | - 요청된 변경을 하지 않고 패치를 다시 제출하는 것 | |
469 | ||
470 | 가능한한 가장 좋은 기술적인 해답을 찾고 있는 커뮤니티에서는 항상 | |
471 | 어떤 패치가 얼마나 좋은지에 관하여 다른 의견들이 있을 수 있다. 여러분은 | |
472 | 협조적이어야 하고 기꺼이 여러분의 생각을 커널 내에 맞추어야 한다. 아니면 | |
473 | 적어도 여러분의 것이 가치있다는 것을 중명하여야 한다. 잘못된 것도 여러분이 | |
474 | 올바른 방향의 해결책으로 이끌어갈 의지가 있다면 받아들여질 것이라는 점을 | |
475 | 기억하라. | |
476 | ||
477 | 여러분의 첫 패치에 여러분이 수정해야하는 십여개 정도의 회신이 오는 | |
478 | 경우도 흔하다. 이것은 여러분의 패치가 받아들여지지 않을 것이라는 것을 | |
479 | 의미하는 것이 아니고 개인적으로 여러분에게 감정이 있어서 그러는 것도 | |
480 | 아니다. 간단히 여러분의 패치에 제기된 문제들을 수정하고 그것을 다시 | |
481 | 보내라. | |
482 | ||
483 | ||
484 | 커널 커뮤니티와 기업 조직간의 차이점 | |
485 | ----------------------------------------------------------------- | |
486 | 커널 커뮤니티는 가장 전통적인 회사의 개발 환경과는 다르다. 여기에 여러분들의 | |
487 | 문제를 피하기 위한 목록이 있다. | |
488 | 여러분들이 제안한 변경들에 관하여 말할 때 좋은 것들 : | |
489 | - " 이것은 여러 문제들을 해겹합니다." | |
490 | - "이것은 2000 라인의 코드를 제거합니다." | |
491 | - "이것은 내가 말하려는 것에 관해 설명하는 패치입니다." | |
492 | - "나는 5개의 다른 아키텍쳐에서 그것을 테스트했슴으로..." | |
493 | - "여기에 일련의 작은 패치들이 있습음로..." | |
494 | - "이것은 일반적인 머신에서 성능을 향상시키므로..." | |
495 | ||
496 | 여러분들이 말할 때 피해야 할 좋지 않은 것들 : | |
497 | - "우리를 그것을 AIT/ptx/Solaris에서 이러한 방법으로 했다. 그러므로 그것은 좋은 것임에 틀립없다..." | |
498 | - "나는 20년동안 이것을 해왔다. 그러므로..." | |
499 | - "이것은 돈을 벌기위해 나의 회사가 필요로 하는 것이다." | |
500 | - "이것은 우리의 엔터프라이즈 상품 라인을 위한 것이다." | |
501 | - "여기에 나의 생각을 말하고 있는 1000 페이지 설계 문서가 있다." | |
502 | - "나는 6달동안 이것을 했으니..." | |
503 | - "여기세 5000라인 짜리 패치가 있으니..." | |
504 | - "나는 현재 뒤죽박죽인 것을 재작성했다. 그리고 여기에..." | |
505 | - "나는 마감시한을 가지고 있으므로 이 패치는 지금 적용될 필요가 있다." | |
506 | ||
507 | 커널 커뮤니티가 전통적인 소프트웨어 엔지니어링 개발 환경들과 | |
508 | 또 다른 점은 얼굴을 보지 않고 일한다는 점이다. 이메일과 irc를 대화의 | |
509 | 주요수단으로 사용하는 것의 한가지 장점은 성별이나 인종의 차별이 | |
510 | 없다는 것이다. 리눅스 커널의 작업 환경에서는 단지 이메일 주소만 | |
511 | 알수 있기 때문에 여성과 소수 민족들도 모두 받아들여진다. 국제적으로 | |
512 | 일하게 되는 측면은 사람의 이름에 근거하여 성별을 추측할 수 없게 | |
513 | 하기때문에 차별을 없애는 데 도움을 준다. Andrea라는 이름을 가진 남자와 | |
514 | Pat이라는 이름을 가진 여자가 있을 수도 있는 것이다. 리눅스 커널에서 | |
515 | 작업하며 생각을 표현해왔던 대부분의 여성들은 긍정적인 경험을 가지고 | |
516 | 있다. | |
517 | ||
518 | 언어 장벽은 영어에 익숙하지 않은 몇몇 사람들에게 문제가 될 수도 있다. | |
519 | 언어의 훌륭한 구사는 메일링 리스트에서 올바르게 자신의 생각을 | |
520 | 표현하기 위하여 필요하다. 그래서 여러분은 이메일을 보내기 전에 | |
521 | 영어를 올바르게 사용하고 있는지를 체크하는 것이 바람직하다. | |
522 | ||
523 | ||
524 | 여러분의 변경을 나누어라 | |
525 | ------------------------ | |
526 | ||
527 | 리눅스 커널 커뮤니티는 한꺼번에 굉장히 큰 코드의 묶음을 쉽게 | |
528 | 받아들이지 않는다. 변경은 적절하게 소개되고, 검토되고, 각각의 | |
529 | 부분으로 작게 나누어져야 한다. 이것은 회사에서 하는 것과는 정확히 | |
530 | 반대되는 것이다. 여러분들의 제안은 개발 초기에 일찍이 소개되야 한다. | |
531 | 그래서 여러분들은 자신이 하고 있는 것에 관하여 피드백을 받을 수 있게 | |
532 | 된다. 커뮤니티가 여러분들이 커뮤니티와 함께 일하고 있다는 것을 | |
533 | 느끼도록 만들고 커뮤니티가 여러분의 기능을 위한 쓰레기 장으로서 | |
534 | 사용되지 않고 있다는 것을 느끼게 하자. 그러나 메일링 리스트에 한번에 | |
535 | 50개의 이메일을 보내지는 말아라. 여러분들의 일련의 패치들은 항상 | |
536 | 더 작아야 한다. | |
537 | ||
538 | 패치를 나누는 이유는 다음과 같다. | |
539 | ||
540 | 1) 작은 패치들은 여러분의 패치들이 적용될 수 있는 확률을 높여준다. | |
541 | 왜냐하면 다른 사람들은 정확성을 검증하기 위하여 많은 시간과 노력을 | |
542 | 들이기를 원하지 않는다. 5줄의 패치는 메인트너가 거의 몇 초간 힐끗 | |
543 | 보면 적용될 수 있다. 그러나 500 줄의 패치는 정확성을 검토하기 위하여 | |
544 | 몇시간이 걸릴 수도 있다(걸리는 시간은 패치의 크기 혹은 다른 것에 | |
545 | 비례하여 기하급수적으로 늘어난다). | |
546 | ||
547 | 패치를 작게 만드는 것은 무엇인가 잘못되었을 때 디버그하는 것을 | |
548 | 쉽게 만든다. 즉, 그렇게 만드는 것은 매우 큰 패치를 적용한 후에 | |
549 | 조사하는 것 보다 작은 패치를 적용한 후에 (그리고 몇몇의 것이 | |
550 | 깨졌을 때) 하나씩 패치들을 제거해가며 디버그 하기 쉽도록 만들어 준다. | |
551 | ||
552 | 2) 작은 패치들을 보내는 것뿐만 아니라 패치들을 제출하기전에 재작성하고 | |
553 | 간단하게(혹은 간단한게 재배치하여) 하는 것도 중요하다. | |
554 | ||
555 | 여기에 커널 개발자 Al Viro의 이야기가 있다. | |
556 | "학생의 수학 숙제를 채점하는 선생님을 생각해보라. 선생님은 학생들이 | |
557 | 답을 얻을때까지 겪은 시행착오를 보길 원하지 않는다. 선생님들은 | |
558 | 간결하고 가장 뛰어난 답을 보길 원한다. 훌륭한 학생은 이것을 알고 | |
559 | 마지막으로 답을 얻기 전 중간 과정들을 제출하진 않는다. | |
560 | ||
561 | 커널 개발도 마찬가지이다. 메인트너들과 검토하는 사람들은 문제를 | |
562 | 풀어나가는 과정속에 숨겨진 과정을 보길 원하진 않는다. 그들은 | |
563 | 간결하고 멋진 답을 보길 원한다." | |
564 | ||
565 | 커뮤니티와 함께 일하며 뛰어난 답을 찾고 여러분들의 완성되지 않은 일들 | |
566 | 사이에 균형을 유지해야 하는 어려움이 있을 수 있다. 그러므로 프로세스의 | |
567 | 초반에 여러분의 일을 향상시키기위한 피드백을 얻는 것 뿐만 아니라 | |
568 | 여러분들의 변경들을 작은 묶음으로 유지해서 심지어는 여러분의 작업의 | |
569 | 모든 부분이 지금은 포함될 준비가 되어있지 않지만 작은 부분은 이미 | |
570 | 받아들여질 수 있도록 유지하는 것이 바람직하다. | |
571 | ||
572 | 또한 완성되지 않았고 "나중에 수정될 것이다." 와 같은 것들은 포함하는 | |
573 | 패치들은 받아들여지지 않을 것이라는 점을 유념하라. | |
574 | ||
575 | 변경을 정당화해라 | |
576 | ----------------- | |
577 | ||
578 | 여러분들의 나누어진 패치들을 리눅스 커뮤니티가 왜 반영해야 하는지를 | |
579 | 알도록 하는 것은 매우 중요하다. 새로운 기능들이 필요하고 유용하다는 | |
580 | 것은 반드시 그에 맞는 이유가 있어야 한다. | |
581 | ||
582 | ||
583 | 변경을 문서화해라 | |
584 | ----------------- | |
585 | ||
586 | 여러분이 패치를 보내려 할때는 여러분이 무엇을 말하려고 하는지를 충분히 | |
587 | 생각하여 이메일을 작성해야 한다. 이 정보는 패치를 위한 ChangeLog가 될 | |
588 | 것이다. 그리고 항상 그 내용을 보길 원하는 모든 사람들을 위해 보존될 | |
589 | 것이다. 패치는 완벽하게 다음과 같은 내용들을 포함하여 설명해야 한다. | |
590 | - 변경이 왜 필요한지 | |
591 | - 패치에 관한 전체 설계 어프로치 | |
592 | - 구현 상세들 | |
593 | - 테스트 결과들 | |
594 | ||
595 | 이것이 무엇인지 더 자세한 것을 알고 싶다면 다음 문서의 ChageLog 항을 봐라. | |
596 | "The Perfect Patch" | |
597 | http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt | |
598 | ||
599 | ||
600 | ||
601 | ||
602 | 이 모든 것을 하는 것은 매우 어려운 일이다. 완벽히 소화하는 데는 적어도 몇년이 | |
603 | 걸릴 수도 있다. 많은 인내와 결의가 필요한 계속되는 개선의 과정이다. 그러나 | |
604 | 가능한한 포기하지 말라. 많은 사람들은 이전부터 해왔던 것이고 그 사람들도 | |
605 | 정확하게 여러분들이 지금 서 있는 그 곳부터 시작했었다. | |
606 | ||
607 | ||
608 | ||
609 | ||
610 | ---------- | |
611 | "개발 프로세스"(http://linux.tar.gz/articles/2.6-development_process) 섹션을 | |
612 | 작성하는데 있어 참고할 문서를 사용하도록 허락해준 Paolo Ciarrocchi에게 | |
613 | 감사한다. 여러분들이 말해야 할 것과 말해서는 안되는 것의 목록 중 일부를 제공해준 | |
614 | Randy Dunlap과 Gerrit Huizenga에게 감사한다. 또한 검토와 의견 그리고 | |
615 | 공헌을 아끼지 않은 Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers, | |
616 | Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton, Andi Kleen, | |
617 | Vadim Lobanov, Jesper Juhl, Adrian Bunk, Keri Harris, Frans Pop, | |
618 | David A. Wheeler, Junio Hamano, Michael Kerrisk, and Alex Shepard에게도 감사를 전한다. | |
619 | 그들의 도움이 없었다면 이 문서는 존재하지 않았을 것이다. | |
620 | ||
621 | ||
622 | ||
623 | 메인트너: Greg Kroah-Hartman <greg@kroah.com> |