forked from ~ljy/RK356X_SDK_RELEASE

hc
2024-05-11 645e752c5a84baeb21015cdc85fc05b7d16312c8
kernel/Documentation/translations/ko_KR/howto.rst
....@@ -77,10 +77,12 @@
7777
7878 리눅스 커널 소스 코드는 GPL로 배포(release)되었다. 소스트리의 메인
7979 디렉토리에 있는 라이센스에 관하여 상세하게 쓰여 있는 COPYING이라는
80
-파일을 봐라. 여러분이 라이센스에 관한 더 깊은 문제를 가지고 있다면
81
-리눅스 커널 메일링 리스트에 묻지말고 변호사와 연락하라. 메일링
82
-리스트들에 있는 사람들은 변호사가 아니기 때문에 법적 문제에 관하여
83
-그들의 말에 의지해서는 안된다.
80
+파일을 봐라. 리눅스 커널 라이센싱 규칙과 소스 코드 안의 `SPDX
81
+<https://spdx.org/>`_ 식별자 사용법은
82
+:ref:`Documentation/process/license-rules.rst <kernel_licensing>` 에 설명되어
83
+있다. 여러분이 라이센스에 관한 더 깊은 문제를 가지고 있다면 리눅스 커널 메일링
84
+리스트에 묻지말고 변호사와 연락하라. 메일링 리스트들에 있는 사람들은 변호사가
85
+아니기 때문에 법적 문제에 관하여 그들의 말에 의지해서는 안된다.
8486
8587 GPL에 관한 잦은 질문들과 답변들은 다음을 참조하라.
8688
....@@ -99,7 +101,7 @@
99101
100102 다음은 커널 소스 트리에 있는 읽어야 할 파일들의 리스트이다.
101103
102
- README
104
+ :ref:`Documentation/admin-guide/README.rst <readme>`
103105 이 파일은 리눅스 커널에 관하여 간단한 배경 설명과 커널을 설정하고
104106 빌드하기 위해 필요한 것을 설명한다. 커널에 입문하는 사람들은 여기서
105107 시작해야 한다.
....@@ -133,7 +135,7 @@
133135 https://www.ozlabs.org/~akpm/stuff/tpp.txt
134136
135137 "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
137139
138140 :ref:`Documentation/process/stable-api-nonsense.rst <stable_api_nonsense>`
139141 이 문서는 의도적으로 커널이 불변하는 API를 갖지 않도록 결정한
....@@ -220,13 +222,6 @@
220222 가지고 있지 않다면 다음에 무엇을 해야할지에 관한 방향을 배울 수 있을
221223 것이다.
222224
223
-여러분들이 이미 커널 트리에 반영하길 원하는 코드 묶음을 가지고 있지만
224
-올바른 포맷으로 포장하는데 도움이 필요하다면 그러한 문제를 돕기 위해
225
-만들어진 kernel-mentors 프로젝트가 있다. 그곳은 메일링 리스트이며
226
-다음에서 참조할 수 있다.
227
-
228
- https://selenic.com/mailman/listinfo/kernel-mentors
229
-
230225 리눅스 커널 코드에 실제 변경을 하기 전에 반드시 그 코드가 어떻게
231226 동작하는지 이해하고 있어야 한다. 코드를 분석하기 위하여 특정한 툴의
232227 도움을 빌려서라도 코드를 직접 읽는 것보다 좋은 것은 없다(대부분의
....@@ -235,7 +230,7 @@
235230 소스코드를 인덱스된 웹 페이지들의 형태로 보여준다. 최신의 멋진 커널
236231 코드 저장소는 다음을 통하여 참조할 수 있다.
237232
238
- http://lxr.free-electrons.com/
233
+ https://elixir.bootlin.com/
239234
240235
241236 개발 프로세스
....@@ -245,22 +240,21 @@
245240 서브시스템에 특화된 커널 브랜치들로 구성된다. 몇몇 다른 메인
246241 브랜치들은 다음과 같다.
247242
248
- - main 4.x 커널 트리
249
- - 4.x.y - 안정된 커널 트리
250
- - 4.x -git 커널 패치들
251
- - 서브시스템을 위한 커널 트리들과 패치들
252
- - 4.x - 통합 테스트를 위한 next 커널 트리
243
+ - 리누스의 메인라인 트리
244
+ - 여러 메이저 넘버를 갖는 다양한 안정된 커널 트리들
245
+ - 서브시스템을 위한 커널 트리들
246
+ - 통합 테스트를 위한 linux-next 커널 트리
253247
254
-4.x 커널 트리
248
+메인라인 트리
255249 ~~~~~~~~~~~~~
256250
257
-4.x 커널들은 Linus Torvalds가 관리하며 https://kernel.org 의
258
-pub/linux/kernel/v4.x/ 디렉토리에서 참조될 수 있다.개발 프로세스는 다음과 같다.
251
+메인라인 트리는 Linus Torvalds가 관리하며 https://kernel.org 또는 소스
252
+저장소에서 참조될 수 있다.개발 프로세스는 다음과 같다.
259253
260254 - 새로운 커널이 배포되자마자 2주의 시간이 주어진다. 이 기간동은
261255 메인테이너들은 큰 diff들을 Linus에게 제출할 수 있다. 대개 이 패치들은
262
- 몇 주 동안 -next 커널내에 이미 있었던 것들이다. 큰 변경들을 제출하는 데
263
- 선호되는 방법은 git(커널의 소스 관리 툴, 더 많은 정보들은
256
+ 몇 주 동안 linux-next 커널내에 이미 있었던 것들이다. 큰 변경들을 제출하는
257
+ 데 선호되는 방법은 git(커널의 소스 관리 툴, 더 많은 정보들은
264258 https://git-scm.com/ 에서 참조할 수 있다)를 사용하는 것이지만 순수한
265259 패치파일의 형식으로 보내는 것도 무관하다.
266260 - 2주 후에 -rc1 커널이 릴리즈되며 여기서부터의 주안점은 새로운 커널을
....@@ -287,36 +281,26 @@
287281 버그의 상황에 따라 배포되는 것이지 미리정해 놓은 시간에 따라
288282 배포되는 것은 아니기 때문이다."*
289283
290
-4.x.y - 안정 커널 트리
291
-~~~~~~~~~~~~~~~~~~~~~~
284
+여러 메이저 넘버를 갖는 다양한 안정된 커널 트리들
285
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
292286
293
-3 자리 숫자로 이루어진 버젼의 커널들은 -stable 커널들이다. 그것들은 4.x
294
-커널에서 발견된 큰 회귀들이나 보안 문제들 중 비교적 작고 중요한 수정들을
295
-포함한다.
287
+세개의 버젼 넘버로 이루어진 버젼의 커널들은 -stable 커널들이다. 그것들은 해당
288
+메이저 메인라인 릴리즈에서 발견된 큰 회귀들이나 보안 문제들 중 비교적 작고
289
+중요한 수정들을 포함한다. 주요 stable 시리즈 릴리즈는 세번째 버젼 넘버를
290
+증가시키며 앞의 두 버젼 넘버는 그대로 유지한다.
296291
297292 이것은 가장 최근의 안정적인 커널을 원하는 사용자에게 추천되는 브랜치이며,
298293 개발/실험적 버젼을 테스트하는 것을 돕고자 하는 사용자들과는 별로 관련이 없다.
299294
300
-어떤 4.x.y 커널도 사용할 수 없다면 그때는 가장 높은 숫자의 4.x
301
-커널이 현재의 안정 커널이다.
295
+-stable 트리들은 "stable" 팀<stable@vger.kernel.org>에 의해 관리되며 거의 매번
296
+격주로 배포된다.
302297
303
-4.x.y는 "stable" 팀<stable@vger.kernel.org>에 의해 관리되며 거의 매번 격주로
304
-배포된다.
298
+커널 트리 문서들 내의 :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
299
+파일은 어떤 종류의 변경들이 -stable 트리로 들어왔는지와
300
+배포 프로세스가 어떻게 진행되는지를 설명한다.
305301
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
+~~~~~~~~~~~~~~~~~~~~~~
320304
321305 다양한 커널 서브시스템의 메인테이너들 --- 그리고 많은 커널 서브시스템 개발자들
322306 --- 은 그들의 현재 개발 상태를 소스 저장소로 노출한다. 이를 통해 다른 사람들도
....@@ -333,22 +317,23 @@
333317 제안된 패치는 서브시스템 트리에 커밋되기 전에 메일링 리스트를 통해
334318 리뷰된다(아래의 관련 섹션을 참고하기 바란다). 일부 커널 서브시스템의 경우, 이
335319 리뷰 프로세스는 patchwork라는 도구를 통해 추적된다. patchwork은 등록된 패치와
336
-패치에 대한 코멘트, 패치의 버전을 볼 수 있는 웹 인터페이스를 제공하고,
320
+패치에 대한 코멘트, 패치의 버젼을 볼 수 있는 웹 인터페이스를 제공하고,
337321 메인테이너는 패치를 리뷰 중, 리뷰 통과, 또는 반려됨으로 표시할 수 있다.
338
-대부분의 이러한 patchwork 사이트는 https://patchwork.kernel.org/ 또는
339
-http://patchwork.ozlabs.org/ 에 나열되어 있다.
322
+대부분의 이러한 patchwork 사이트는 https://patchwork.kernel.org/ 에 나열되어
323
+있다.
340324
341
-4.x - 통합 테스트를 위한 next 커널 트리
342
----------------------------------------
343
-서브시스템 트리들의 변경사항들은 mainline 4.x 트리로 들어오기 전에 통합
344
-테스트를 거쳐야 한다. 이런 목적으로, 모든 서브시스템 트리의 변경사항을 거의
345
-매일 받아가는 특수한 테스트 저장소가 존재한다:
325
+통합 테스트를 위한 linux-next 커널 트리
326
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
346327
347
- https://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git
328
+서브시스템 트리들의 변경사항들은 mainline 트리로 들어오기 전에 통합 테스트를
329
+거쳐야 한다. 이런 목적으로, 모든 서브시스템 트리의 변경사항을 거의 매일
330
+받아가는 특수한 테스트 저장소가 존재한다:
348331
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
+커널에서 테스트를 수행하는 것도 좋을 것이다.
352337
353338
354339 버그 보고
....@@ -360,9 +345,10 @@
360345
361346 https://bugzilla.kernel.org/page.cgi?id=faq.html
362347
363
-메인 커널 소스 디렉토리에 있는 admin-guide/reporting-bugs.rst 파일은 커널 버그라고 생각되는
364
-것을 보고하는 방법에 관한 좋은 템플릿이며 문제를 추적하기 위해서 커널
365
-개발자들이 필요로 하는 정보가 무엇들인지를 상세히 설명하고 있다.
348
+메인 커널 소스 디렉토리에 있는 :ref:`admin-guide/reporting-bugs.rst <reportingbugs>`
349
+파일은 커널 버그라고 생각되는 것을 보고하는 방법에 관한 좋은 템플릿이며 문제를
350
+추적하기 위해서 커널 개발자들이 필요로 하는 정보가 무엇들인지를 상세히 설명하고
351
+있다.
366352
367353
368354 버그 리포트들의 관리
....@@ -377,15 +363,7 @@
377363 다른 사람들의 버그들을 수정하기 위하여 시간을 낭비하지 않기 때문이다.
378364
379365 이미 보고된 버그 리포트들을 가지고 작업하기 위해서 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
+를 참조하라.
389367
390368
391369 메일링 리스트들
....@@ -430,7 +408,8 @@
430408 "John 커널해커는 작성했다...."를 유지하며 여러분들의 의견을 그 메일의 윗부분에
431409 작성하지 말고 각 인용한 단락들 사이에 넣어라.
432410
433
-여러분들이 패치들을 메일에 넣는다면 그것들은 Documentation/process/submitting-patches.rst에
411
+여러분들이 패치들을 메일에 넣는다면 그것들은
412
+:ref:`Documentation/process/submitting-patches.rst <submittingpatches>` 에
434413 나와있는데로 명백히(plain) 읽을 수 있는 텍스트여야 한다. 커널 개발자들은
435414 첨부파일이나 압축된 패치들을 원하지 않는다. 그들은 여러분들의 패치의
436415 각 라인 단위로 코멘트를 하길 원하며 압축하거나 첨부하지 않고 보내는 것이