.. | .. |
---|
77 | 77 | |
---|
78 | 78 | 리눅스 커널 소스 코드는 GPL로 배포(release)되었다. 소스트리의 메인 |
---|
79 | 79 | 디렉토리에 있는 라이센스에 관하여 상세하게 쓰여 있는 COPYING이라는 |
---|
80 | | -파일을 봐라. 여러분이 라이센스에 관한 더 깊은 문제를 가지고 있다면 |
---|
81 | | -리눅스 커널 메일링 리스트에 묻지말고 변호사와 연락하라. 메일링 |
---|
82 | | -리스트들에 있는 사람들은 변호사가 아니기 때문에 법적 문제에 관하여 |
---|
83 | | -그들의 말에 의지해서는 안된다. |
---|
| 80 | +파일을 봐라. 리눅스 커널 라이센싱 규칙과 소스 코드 안의 `SPDX |
---|
| 81 | +<https://spdx.org/>`_ 식별자 사용법은 |
---|
| 82 | +:ref:`Documentation/process/license-rules.rst <kernel_licensing>` 에 설명되어 |
---|
| 83 | +있다. 여러분이 라이센스에 관한 더 깊은 문제를 가지고 있다면 리눅스 커널 메일링 |
---|
| 84 | +리스트에 묻지말고 변호사와 연락하라. 메일링 리스트들에 있는 사람들은 변호사가 |
---|
| 85 | +아니기 때문에 법적 문제에 관하여 그들의 말에 의지해서는 안된다. |
---|
84 | 86 | |
---|
85 | 87 | GPL에 관한 잦은 질문들과 답변들은 다음을 참조하라. |
---|
86 | 88 | |
---|
.. | .. |
---|
99 | 101 | |
---|
100 | 102 | 다음은 커널 소스 트리에 있는 읽어야 할 파일들의 리스트이다. |
---|
101 | 103 | |
---|
102 | | - README |
---|
| 104 | + :ref:`Documentation/admin-guide/README.rst <readme>` |
---|
103 | 105 | 이 파일은 리눅스 커널에 관하여 간단한 배경 설명과 커널을 설정하고 |
---|
104 | 106 | 빌드하기 위해 필요한 것을 설명한다. 커널에 입문하는 사람들은 여기서 |
---|
105 | 107 | 시작해야 한다. |
---|
.. | .. |
---|
133 | 135 | https://www.ozlabs.org/~akpm/stuff/tpp.txt |
---|
134 | 136 | |
---|
135 | 137 | "Linux kernel patch submission format" |
---|
136 | | - http://linux.yyz.us/patch-format.html |
---|
| 138 | + https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html |
---|
137 | 139 | |
---|
138 | 140 | :ref:`Documentation/process/stable-api-nonsense.rst <stable_api_nonsense>` |
---|
139 | 141 | 이 문서는 의도적으로 커널이 불변하는 API를 갖지 않도록 결정한 |
---|
.. | .. |
---|
220 | 222 | 가지고 있지 않다면 다음에 무엇을 해야할지에 관한 방향을 배울 수 있을 |
---|
221 | 223 | 것이다. |
---|
222 | 224 | |
---|
223 | | -여러분들이 이미 커널 트리에 반영하길 원하는 코드 묶음을 가지고 있지만 |
---|
224 | | -올바른 포맷으로 포장하는데 도움이 필요하다면 그러한 문제를 돕기 위해 |
---|
225 | | -만들어진 kernel-mentors 프로젝트가 있다. 그곳은 메일링 리스트이며 |
---|
226 | | -다음에서 참조할 수 있다. |
---|
227 | | - |
---|
228 | | - https://selenic.com/mailman/listinfo/kernel-mentors |
---|
229 | | - |
---|
230 | 225 | 리눅스 커널 코드에 실제 변경을 하기 전에 반드시 그 코드가 어떻게 |
---|
231 | 226 | 동작하는지 이해하고 있어야 한다. 코드를 분석하기 위하여 특정한 툴의 |
---|
232 | 227 | 도움을 빌려서라도 코드를 직접 읽는 것보다 좋은 것은 없다(대부분의 |
---|
.. | .. |
---|
235 | 230 | 소스코드를 인덱스된 웹 페이지들의 형태로 보여준다. 최신의 멋진 커널 |
---|
236 | 231 | 코드 저장소는 다음을 통하여 참조할 수 있다. |
---|
237 | 232 | |
---|
238 | | - http://lxr.free-electrons.com/ |
---|
| 233 | + https://elixir.bootlin.com/ |
---|
239 | 234 | |
---|
240 | 235 | |
---|
241 | 236 | 개발 프로세스 |
---|
.. | .. |
---|
245 | 240 | 서브시스템에 특화된 커널 브랜치들로 구성된다. 몇몇 다른 메인 |
---|
246 | 241 | 브랜치들은 다음과 같다. |
---|
247 | 242 | |
---|
248 | | - - main 4.x 커널 트리 |
---|
249 | | - - 4.x.y - 안정된 커널 트리 |
---|
250 | | - - 4.x -git 커널 패치들 |
---|
251 | | - - 서브시스템을 위한 커널 트리들과 패치들 |
---|
252 | | - - 4.x - 통합 테스트를 위한 next 커널 트리 |
---|
| 243 | + - 리누스의 메인라인 트리 |
---|
| 244 | + - 여러 메이저 넘버를 갖는 다양한 안정된 커널 트리들 |
---|
| 245 | + - 서브시스템을 위한 커널 트리들 |
---|
| 246 | + - 통합 테스트를 위한 linux-next 커널 트리 |
---|
253 | 247 | |
---|
254 | | -4.x 커널 트리 |
---|
| 248 | +메인라인 트리 |
---|
255 | 249 | ~~~~~~~~~~~~~ |
---|
256 | 250 | |
---|
257 | | -4.x 커널들은 Linus Torvalds가 관리하며 https://kernel.org 의 |
---|
258 | | -pub/linux/kernel/v4.x/ 디렉토리에서 참조될 수 있다.개발 프로세스는 다음과 같다. |
---|
| 251 | +메인라인 트리는 Linus Torvalds가 관리하며 https://kernel.org 또는 소스 |
---|
| 252 | +저장소에서 참조될 수 있다.개발 프로세스는 다음과 같다. |
---|
259 | 253 | |
---|
260 | 254 | - 새로운 커널이 배포되자마자 2주의 시간이 주어진다. 이 기간동은 |
---|
261 | 255 | 메인테이너들은 큰 diff들을 Linus에게 제출할 수 있다. 대개 이 패치들은 |
---|
262 | | - 몇 주 동안 -next 커널내에 이미 있었던 것들이다. 큰 변경들을 제출하는 데 |
---|
263 | | - 선호되는 방법은 git(커널의 소스 관리 툴, 더 많은 정보들은 |
---|
| 256 | + 몇 주 동안 linux-next 커널내에 이미 있었던 것들이다. 큰 변경들을 제출하는 |
---|
| 257 | + 데 선호되는 방법은 git(커널의 소스 관리 툴, 더 많은 정보들은 |
---|
264 | 258 | https://git-scm.com/ 에서 참조할 수 있다)를 사용하는 것이지만 순수한 |
---|
265 | 259 | 패치파일의 형식으로 보내는 것도 무관하다. |
---|
266 | 260 | - 2주 후에 -rc1 커널이 릴리즈되며 여기서부터의 주안점은 새로운 커널을 |
---|
.. | .. |
---|
287 | 281 | 버그의 상황에 따라 배포되는 것이지 미리정해 놓은 시간에 따라 |
---|
288 | 282 | 배포되는 것은 아니기 때문이다."* |
---|
289 | 283 | |
---|
290 | | -4.x.y - 안정 커널 트리 |
---|
291 | | -~~~~~~~~~~~~~~~~~~~~~~ |
---|
| 284 | +여러 메이저 넘버를 갖는 다양한 안정된 커널 트리들 |
---|
| 285 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
---|
292 | 286 | |
---|
293 | | -3 자리 숫자로 이루어진 버젼의 커널들은 -stable 커널들이다. 그것들은 4.x |
---|
294 | | -커널에서 발견된 큰 회귀들이나 보안 문제들 중 비교적 작고 중요한 수정들을 |
---|
295 | | -포함한다. |
---|
| 287 | +세개의 버젼 넘버로 이루어진 버젼의 커널들은 -stable 커널들이다. 그것들은 해당 |
---|
| 288 | +메이저 메인라인 릴리즈에서 발견된 큰 회귀들이나 보안 문제들 중 비교적 작고 |
---|
| 289 | +중요한 수정들을 포함한다. 주요 stable 시리즈 릴리즈는 세번째 버젼 넘버를 |
---|
| 290 | +증가시키며 앞의 두 버젼 넘버는 그대로 유지한다. |
---|
296 | 291 | |
---|
297 | 292 | 이것은 가장 최근의 안정적인 커널을 원하는 사용자에게 추천되는 브랜치이며, |
---|
298 | 293 | 개발/실험적 버젼을 테스트하는 것을 돕고자 하는 사용자들과는 별로 관련이 없다. |
---|
299 | 294 | |
---|
300 | | -어떤 4.x.y 커널도 사용할 수 없다면 그때는 가장 높은 숫자의 4.x |
---|
301 | | -커널이 현재의 안정 커널이다. |
---|
| 295 | +-stable 트리들은 "stable" 팀<stable@vger.kernel.org>에 의해 관리되며 거의 매번 |
---|
| 296 | +격주로 배포된다. |
---|
302 | 297 | |
---|
303 | | -4.x.y는 "stable" 팀<stable@vger.kernel.org>에 의해 관리되며 거의 매번 격주로 |
---|
304 | | -배포된다. |
---|
| 298 | +커널 트리 문서들 내의 :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>` |
---|
| 299 | +파일은 어떤 종류의 변경들이 -stable 트리로 들어왔는지와 |
---|
| 300 | +배포 프로세스가 어떻게 진행되는지를 설명한다. |
---|
305 | 301 | |
---|
306 | | -커널 트리 문서들 내에 Documentation/process/stable-kernel-rules.rst 파일은 어떤 |
---|
307 | | -종류의 변경들이 -stable 트리로 들어왔는지와 배포 프로세스가 어떻게 |
---|
308 | | -진행되는지를 설명한다. |
---|
309 | | - |
---|
310 | | -4.x -git 패치들 |
---|
311 | | -~~~~~~~~~~~~~~~ |
---|
312 | | - |
---|
313 | | -git 저장소(그러므로 -git이라는 이름이 붙음)에는 날마다 관리되는 Linus의 |
---|
314 | | -커널 트리의 snapshot 들이 있다. 이 패치들은 일반적으로 날마다 배포되며 |
---|
315 | | -Linus의 트리의 현재 상태를 나타낸다. 이 패치들은 정상적인지 조금도 |
---|
316 | | -살펴보지 않고 자동적으로 생성된 것이므로 -rc 커널들 보다도 더 실험적이다. |
---|
317 | | - |
---|
318 | | -서브시스템 커널 트리들과 패치들 |
---|
319 | | -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
---|
| 302 | +서브시스템 커널 트리들 |
---|
| 303 | +~~~~~~~~~~~~~~~~~~~~~~ |
---|
320 | 304 | |
---|
321 | 305 | 다양한 커널 서브시스템의 메인테이너들 --- 그리고 많은 커널 서브시스템 개발자들 |
---|
322 | 306 | --- 은 그들의 현재 개발 상태를 소스 저장소로 노출한다. 이를 통해 다른 사람들도 |
---|
.. | .. |
---|
333 | 317 | 제안된 패치는 서브시스템 트리에 커밋되기 전에 메일링 리스트를 통해 |
---|
334 | 318 | 리뷰된다(아래의 관련 섹션을 참고하기 바란다). 일부 커널 서브시스템의 경우, 이 |
---|
335 | 319 | 리뷰 프로세스는 patchwork라는 도구를 통해 추적된다. patchwork은 등록된 패치와 |
---|
336 | | -패치에 대한 코멘트, 패치의 버전을 볼 수 있는 웹 인터페이스를 제공하고, |
---|
| 320 | +패치에 대한 코멘트, 패치의 버젼을 볼 수 있는 웹 인터페이스를 제공하고, |
---|
337 | 321 | 메인테이너는 패치를 리뷰 중, 리뷰 통과, 또는 반려됨으로 표시할 수 있다. |
---|
338 | | -대부분의 이러한 patchwork 사이트는 https://patchwork.kernel.org/ 또는 |
---|
339 | | -http://patchwork.ozlabs.org/ 에 나열되어 있다. |
---|
| 322 | +대부분의 이러한 patchwork 사이트는 https://patchwork.kernel.org/ 에 나열되어 |
---|
| 323 | +있다. |
---|
340 | 324 | |
---|
341 | | -4.x - 통합 테스트를 위한 next 커널 트리 |
---|
342 | | ---------------------------------------- |
---|
343 | | -서브시스템 트리들의 변경사항들은 mainline 4.x 트리로 들어오기 전에 통합 |
---|
344 | | -테스트를 거쳐야 한다. 이런 목적으로, 모든 서브시스템 트리의 변경사항을 거의 |
---|
345 | | -매일 받아가는 특수한 테스트 저장소가 존재한다: |
---|
| 325 | +통합 테스트를 위한 linux-next 커널 트리 |
---|
| 326 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
---|
346 | 327 | |
---|
347 | | - https://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git |
---|
| 328 | +서브시스템 트리들의 변경사항들은 mainline 트리로 들어오기 전에 통합 테스트를 |
---|
| 329 | +거쳐야 한다. 이런 목적으로, 모든 서브시스템 트리의 변경사항을 거의 매일 |
---|
| 330 | +받아가는 특수한 테스트 저장소가 존재한다: |
---|
348 | 331 | |
---|
349 | | -이런 식으로, -next 커널을 통해 다음 머지 기간에 메인라인 커널에 어떤 변경이 |
---|
350 | | -가해질 것인지 간략히 알 수 있다. 모험심 강한 테스터라면 -next 커널에서 테스트를 |
---|
351 | | -수행하는 것도 좋을 것이다. |
---|
| 332 | + https://git.kernel.org/?p=linux/kernel/git/next/linux-next.git |
---|
| 333 | + |
---|
| 334 | +이런 식으로, linux-next 커널을 통해 다음 머지 기간에 메인라인 커널에 어떤 |
---|
| 335 | +변경이 가해질 것인지 간략히 알 수 있다. 모험심 강한 테스터라면 linux-next |
---|
| 336 | +커널에서 테스트를 수행하는 것도 좋을 것이다. |
---|
352 | 337 | |
---|
353 | 338 | |
---|
354 | 339 | 버그 보고 |
---|
.. | .. |
---|
360 | 345 | |
---|
361 | 346 | https://bugzilla.kernel.org/page.cgi?id=faq.html |
---|
362 | 347 | |
---|
363 | | -메인 커널 소스 디렉토리에 있는 admin-guide/reporting-bugs.rst 파일은 커널 버그라고 생각되는 |
---|
364 | | -것을 보고하는 방법에 관한 좋은 템플릿이며 문제를 추적하기 위해서 커널 |
---|
365 | | -개발자들이 필요로 하는 정보가 무엇들인지를 상세히 설명하고 있다. |
---|
| 348 | +메인 커널 소스 디렉토리에 있는 :ref:`admin-guide/reporting-bugs.rst <reportingbugs>` |
---|
| 349 | +파일은 커널 버그라고 생각되는 것을 보고하는 방법에 관한 좋은 템플릿이며 문제를 |
---|
| 350 | +추적하기 위해서 커널 개발자들이 필요로 하는 정보가 무엇들인지를 상세히 설명하고 |
---|
| 351 | +있다. |
---|
366 | 352 | |
---|
367 | 353 | |
---|
368 | 354 | 버그 리포트들의 관리 |
---|
.. | .. |
---|
377 | 363 | 다른 사람들의 버그들을 수정하기 위하여 시간을 낭비하지 않기 때문이다. |
---|
378 | 364 | |
---|
379 | 365 | 이미 보고된 버그 리포트들을 가지고 작업하기 위해서 https://bugzilla.kernel.org |
---|
380 | | -를 참조하라. 여러분이 앞으로 생겨날 버그 리포트들의 조언자가 되길 원한다면 |
---|
381 | | -bugme-new 메일링 리스트나(새로운 버그 리포트들만이 이곳에서 메일로 전해진다) |
---|
382 | | -bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메일로 전해진다) |
---|
383 | | -에 등록하면 된다. |
---|
384 | | - |
---|
385 | | - https://lists.linux-foundation.org/mailman/listinfo/bugme-new |
---|
386 | | - |
---|
387 | | - https://lists.linux-foundation.org/mailman/listinfo/bugme-janitors |
---|
388 | | - |
---|
| 366 | +를 참조하라. |
---|
389 | 367 | |
---|
390 | 368 | |
---|
391 | 369 | 메일링 리스트들 |
---|
.. | .. |
---|
430 | 408 | "John 커널해커는 작성했다...."를 유지하며 여러분들의 의견을 그 메일의 윗부분에 |
---|
431 | 409 | 작성하지 말고 각 인용한 단락들 사이에 넣어라. |
---|
432 | 410 | |
---|
433 | | -여러분들이 패치들을 메일에 넣는다면 그것들은 Documentation/process/submitting-patches.rst에 |
---|
| 411 | +여러분들이 패치들을 메일에 넣는다면 그것들은 |
---|
| 412 | +:ref:`Documentation/process/submitting-patches.rst <submittingpatches>` 에 |
---|
434 | 413 | 나와있는데로 명백히(plain) 읽을 수 있는 텍스트여야 한다. 커널 개발자들은 |
---|
435 | 414 | 첨부파일이나 압축된 패치들을 원하지 않는다. 그들은 여러분들의 패치의 |
---|
436 | 415 | 각 라인 단위로 코멘트를 하길 원하며 압축하거나 첨부하지 않고 보내는 것이 |
---|