This commit applies commit 022e04d6f555 ("Documentation/HOWTO: convert
to ReST notation") to Korean translation and fix a trivial ReST build
failure problem.
Signed-off-by: SeongJae Park <sj38.park@xxxxxxxxx>
---
Documentation/ko_KR/HOWTO | 58 +++++++++++++++++++++++++++++++++++++++++++----
1 file changed, 53 insertions(+), 5 deletions(-)
diff --git a/Documentation/ko_KR/HOWTO b/Documentation/ko_KR/HOWTO
index 4048297e48aa..78dab436a926 100644
--- a/Documentation/ko_KR/HOWTO
+++ b/Documentation/ko_KR/HOWTO
@@ -9,17 +9,20 @@ read for non English (read: korean) speakers and is not intended as
a fork. So if you have any comments or updates for this file please
try to update the original English file first.
-==================================
+----------------------------------
+
이 문서는
Documentation/HOWTO
의 한글 번역입니다.
역자： 김민찬 <minchan@xxxxxxxxxx>
감수： 이제이미 <jamee.lee@xxxxxxxxxxx>
-==================================
+
+----------------------------------
+
어떻게 리눅스 커널 개발을 하는가
----------------------------------
+================================
이 문서는 커널 개발에 있어 가장 중요한 문서이다. 이 문서는
리눅스 커널 개발자가 되는 법과 리눅스 커널 개발 커뮤니티와 일하는
@@ -46,6 +49,7 @@ Documentation/HOWTO
어셈블리(특정 아키텍쳐)는 잘 알아야 할 필요는 없다.
다음의 참고서적들은 기본에 충실한 C 교육이나 수년간의 경험에 견주지는
못하지만 적어도 참고 용도로는 좋을 것이다
+
- "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]
- "Practical C Programming" by Steve Oualline [O'Reilly]
- "C: A Reference Manual" by Harbison and Steele [Prentice Hall]
@@ -79,6 +83,7 @@ Documentation/HOWTO
그들의 말에 의지해서는 안된다.
GPL에 관한 잦은 질문들과 답변들은 다음을 참조하라.
+
http://www.gnu.org/licenses/gpl-faq.html
@@ -93,6 +98,7 @@ GPL에 관한 잦은 질문들과 답변들은 다음을 참조하라.
mtk.manpages@xxxxxxxxx의 메인테이너에게 보낼 것을 권장한다.
다음은 커널 소스 트리에 있는 읽어야 할 파일들의 리스트이다.
+
README
이 파일은 리눅스 커널에 관하여 간단한 배경 설명과 커널을 설정하고
빌드하기 위해 필요한 것을 설명한다. 커널에 입문하는 사람들은 여기서
@@ -108,30 +114,37 @@ mtk.manpages@xxxxxxxxx의 메인테이너에게 보낼 것을 권장한다.
메인테이너들은 이 규칙을 따르는 패치들만을 받아들일 것이고 많은 사람들이
그 패치가 올바른 스타일일 경우만 코드를 검토할 것이다.
- Documentation/SubmittingPatches
- Documentation/SubmittingDrivers
+ Documentation/SubmittingPatches 와 Documentation/SubmittingDrivers
이 파일들은 성공적으로 패치를 만들고 보내는 법을 다음의 내용들로
굉장히 상세히 설명하고 있다(그러나 다음으로 한정되진 않는다).
+
- Email 내용들
- Email 양식
- 그것을 누구에게 보낼지
+
이러한 규칙들을 따르는 것이 성공(역자주: 패치가 받아들여 지는 것)을
보장하진 않는다(왜냐하면 모든 패치들은 내용과 스타일에 관하여
면밀히 검토되기 때문이다). 그러나 규칙을 따르지 않는다면 거의
성공하지도 못할 것이다.
올바른 패치들을 만드는 법에 관한 훌륭한 다른 문서들이 있다.
+
"The Perfect Patch"
+
http://www.ozlabs.org/~akpm/stuff/tpp.txt
+
"Linux kernel patch submission format"
+
http://linux.yyz.us/patch-format.html
Documentation/stable_api_nonsense.txt
이 문서는 의도적으로 커널이 불변하는 API를 갖지 않도록 결정한
이유를 설명하며 다음과 같은 것들을 포함한다.
+
- 서브시스템 shim-layer(호환성을 위해?)
- 운영체제들간의 드라이버 이식성
- 커널 소스 트리내에 빠른 변화를 늦추는 것(또는 빠른 변화를 막는 것)
+
이 문서는 리눅스 개발 철학을 이해하는데 필수적이며 다른 운영체제에서
리눅스로 전향하는 사람들에게는 매우 중요하다.
@@ -168,10 +181,14 @@ mtk.manpages@xxxxxxxxx의 메인테이너에게 보낼 것을 권장한다.
올바르게 처리하는 법에 관한 규칙을 포함하고 있다. 이 문서는
Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, HTML,
그리고 man 페이지들로 다음과 같이 실행하여 만들어 진다.
+
+::
+
make pdfdocs
make psdocs
make htmldocs
make mandocs
+
각각의 명령을 메인 커널 소스 디렉토리로부터 실행한다.
@@ -180,7 +197,9 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H
여러분이 리눅스 커널 개발에 관하여 아무것도 모른다면 Linux KernelNewbies
프로젝트를 봐야 한다.
+
http://kernelnewbies.org
+
그곳은 거의 모든 종류의 기본적인 커널 개발 질문들(질문하기 전에 먼저
아카이브를 찾아봐라. 과거에 이미 답변되었을 수도 있다)을 할 수 있는 도움이
될만한 메일링 리스트가 있다. 또한 실시간으로 질문 할 수 있는 IRC 채널도
@@ -192,7 +211,9 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H
여러분이 어디서 시작해야 할진 모르지만 커널 개발 커뮤니티에 참여할 수
있는 일들을 찾길 원한다면 리눅스 커널 Janitor 프로젝트를 살펴봐라.
+
http://kernelnewbies.org/KernelJanitors
+
그곳은 시작하기에 훌륭한 장소이다. 그곳은 리눅스 커널 소스 트리내에
간단히 정리되고 수정될 수 있는 문제들에 관하여 설명한다. 여러분은 이
프로젝트를 대표하는 개발자들과 일하면서 자신의 패치를 리눅스 커널 트리에
@@ -204,6 +225,7 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H
올바른 포맷으로 포장하는데 도움이 필요하다면 그러한 문제를 돕기 위해
만들어진 kernel-mentors 프로젝트가 있다. 그곳은 메일링 리스트이며
다음에서 참조할 수 있다.
+
http://selenic.com/mailman/listinfo/kernel-mentors
리눅스 커널 코드에 실제 변경을 하기 전에 반드시 그 코드가 어떻게
@@ -213,6 +235,7 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H
것은 Linux Cross-Reference project이며 그것은 자기 참조 방식이며
소스코드를 인덱스된 웹 페이지들의 형태로 보여준다. 최신의 멋진 커널
코드 저장소는 다음을 통하여 참조할 수 있다.
+
http://lxr.free-electrons.com/
@@ -222,6 +245,7 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H
리눅스 커널 개발 프로세스는 현재 몇몇 다른 메인 커널 "브랜치들"과
서브시스템에 특화된 커널 브랜치들로 구성된다. 몇몇 다른 메인
브랜치들은 다음과 같다.
+
- main 4.x 커널 트리
- 4.x.y - 안정된 커널 트리
- 4.x -git 커널 패치들
@@ -232,6 +256,7 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H
-------------
4.x 커널들은 Linus Torvalds가 관리하며 kernel.org의 pub/linux/kernel/v4.x/
디렉토리에서 참조될 수 있다.개발 프로세스는 다음과 같다.
+
- 새로운 커널이 배포되자마자 2주의 시간이 주어진다. 이 기간동은
메인테이너들은 큰 diff들을 Linus에게 제출할 수 있다. 대개 이 패치들은
몇 주 동안 -next 커널내에 이미 있었던 것들이다. 큰 변경들을 제출하는 데
@@ -255,6 +280,9 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H
커널 배포에 있어서 언급할만한 가치가 있는 리눅스 커널 메일링 리스트의
Andrew Morton의 글이 있다.
+
+::
+
"커널이 언제 배포될지는 아무도 모른다. 왜냐하면 배포는 알려진
버그의 상황에 따라 배포되는 것이지 미리정해 놓은 시간에 따라
배포되는 것은 아니기 때문이다."
@@ -312,6 +340,7 @@ http://patchwork.ozlabs.org/ 에 나열되어 있다.
서브시스템 트리들의 변경사항들은 mainline 4.x 트리로 들어오기 전에 통합
테스트를 거쳐야 한다. 이런 목적으로, 모든 서브시스템 트리의 변경사항을 거의
매일 받아가는 특수한 테스트 저장소가 존재한다:
+
http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git
이런 식으로, -next 커널을 통해 다음 머지 기간에 메인라인 커널에 어떤 변경이
@@ -325,6 +354,7 @@ http://patchwork.ozlabs.org/ 에 나열되어 있다.
bugzilla.kernel.org는 리눅스 커널 개발자들이 커널의 버그를 추적하는 곳이다.
사용자들은 발견한 모든 버그들을 보고하기 위하여 이 툴을 사용할 것을 권장한다.
kernel bugzilla를 사용하는 자세한 방법은 다음을 참조하라.
+
http://bugzilla.kernel.org/page.cgi?id=faq.html
메인 커널 소스 디렉토리에 있는 REPORTING-BUGS 파일은 커널 버그라고 생각되는
@@ -360,10 +390,14 @@ bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메
위의 몇몇 문서들이 설명하였지만 핵심 커널 개발자들의 대다수는
리눅스 커널 메일링 리스트에 참여하고 있다. 리스트에 등록하고 해지하는
방법에 관한 자세한 사항은 다음에서 참조할 수 있다.
+
http://vger.kernel.org/vger-lists.html#linux-kernel
+
웹상의 많은 다른 곳에도 메일링 리스트의 아카이브들이 있다.
이러한 아카이브들을 찾으려면 검색 엔진을 사용하라. 예를 들어:
+
http://dir.gmane.org/gmane.linux.kernel
+
여러분이 새로운 문제에 관해 리스트에 올리기 전에 말하고 싶은 주제에 관한
것을 아카이브에서 먼저 찾아보기를 강력히 권장한다. 이미 상세하게 토론된 많은
것들이 메일링 리스트의 아카이브에 기록되어 있다.
@@ -373,11 +407,13 @@ bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메
있는지는 MAINTAINERS 파일을 참조하라.
많은 리스트들은 kernel.org에서 호스트되고 있다. 그 정보들은 다음에서 참조될 수 있다.
+
http://vger.kernel.org/vger-lists.html
리스트들을 사용할 때는 올바른 예절을 따를 것을 유념해라.
대단하진 않지만 다음 URL은 리스트(혹은 모든 리스트)와 대화하는 몇몇 간단한
가이드라인을 가지고 있다.
+
http://www.albion.com/netiquette/
여러 사람들이 여러분의 메일에 응답한다면 CC: 즉 수신 리스트는 꽤 커지게
@@ -409,6 +445,7 @@ bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메
커널 커뮤니티의 목적은 가능한한 가장 좋은 커널을 제공하는 것이다. 여러분이
받아들여질 패치를 제출하게 되면 그 패치의 기술적인 이점으로 검토될 것이다.
그럼 여러분들은 무엇을 기대하고 있어야 하는가?
+
- 비판
- 의견
- 변경을 위한 요구
@@ -422,6 +459,7 @@ bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메
기다려보고 다시 시도해라. 때론 너무 많은 메일들 속에 묻혀버리기도 한다.
여러분은 무엇을 해서는 안되는가?
+
- 여러분의 패치가 아무 질문 없이 받아들여지기를 기대하는 것
- 방어적이 되는 것
- 의견을 무시하는 것
@@ -445,7 +483,9 @@ bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메
------------------------------------
커널 커뮤니티는 가장 전통적인 회사의 개발 환경과는 다르다. 여기에 여러분들의
문제를 피하기 위한 목록이 있다.
+
여러분들이 제안한 변경들에 관하여 말할 때 좋은 것들 :
+
- "이것은 여러 문제들을 해결합니다."
- "이것은 2000 라인의 코드를 줄입니다."
- "이것은 내가 말하려는 것에 관해 설명하는 패치입니다."
@@ -454,6 +494,7 @@ bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메
- "이것은 일반적인 머신에서 성능을 향상함으로..."
여러분들이 말할 때 피해야 할 좋지 않은 것들 :
+
- "우리는 그것을 AIX/ptx/Solaris에서 이러한 방법으로 했다. 그러므로 그것은 좋은 것임에 틀림없다..."
- "나는 20년동안 이것을 해왔다. 그러므로..."
- "이것은 돈을 벌기위해 나의 회사가 필요로 하는 것이다."
@@ -513,6 +554,9 @@ Pat이라는 이름을 가진 여자가 있을 수도 있는 것이다. 리눅
간단하게(혹은 간단한게 재배치하여) 하는 것도 중요하다.
여기에 커널 개발자 Al Viro의 이야기가 있다.
+
+::
+
"학생의 수학 숙제를 채점하는 선생님을 생각해보라. 선생님은 학생들이
답을 얻을때까지 겪은 시행착오를 보길 원하지 않는다. 선생님들은
간결하고 가장 뛰어난 답을 보길 원한다. 훌륭한 학생은 이것을 알고
@@ -548,13 +592,16 @@ Pat이라는 이름을 가진 여자가 있을 수도 있는 것이다. 리눅
생각하여 이메일을 작성해야 한다. 이 정보는 패치를 위한 ChangeLog가 될
것이다. 그리고 항상 그 내용을 보길 원하는 모든 사람들을 위해 보존될
것이다. 패치는 완벽하게 다음과 같은 내용들을 포함하여 설명해야 한다.
+
- 변경이 왜 필요한지
- 패치에 관한 전체 설계 접근(approach)
- 구현 상세들
- 테스트 결과들
이것이 무엇인지 더 자세한 것을 알고 싶다면 다음 문서의 ChageLog 항을 봐라.
+
"The Perfect Patch"
+
http://www.ozlabs.org/~akpm/stuff/tpp.txt
@@ -569,6 +616,7 @@ Pat이라는 이름을 가진 여자가 있을 수도 있는 것이다. 리눅
----------
+
"개발 프로세스"(http://lwn.net/Articles/94386/) 섹션을
작성하는데 있어 참고할 문서를 사용하도록 허락해준 Paolo Ciarrocchi에게
감사한다. 여러분들이 말해야 할 것과 말해서는 안되는 것의 목록 중 일부를 제공해준
--
2.10.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
