About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / ko_KR / HOWTO




Custom Search

Based on kernel version 3.19. Page generated on 2015-02-13 21:21 EST.

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@gmail.com의 메인테이너에게 보낼 것을 권장한다.
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	    올바른 패치들을 만드는 법에 관한 훌륭한 다른 문서들이 있다.
124	    "The Perfect Patch"
125	        http://www.ozlabs.org/~akpm/stuff/tpp.txt
126	    "Linux kernel patch submission format"
127	        http://linux.yyz.us/patch-format.html
128	
129	   Documentation/stable_api_nonsense.txt
130	    이 문서는 의도적으로 커널이 불변하는 API를 갖지 않도록 결정한
131	    이유를 설명하며 다음과 같은 것들을 포함한다.
132	       - 서브시스템 shim-layer(호환성을 위해?)
133	       - 운영체제들간의 드라이버 이식성
134	       - 커널 소스 트리내에 빠른 변화를 늦추는 것(또는 빠른 변화를 막는 것)
135	    이 문서는 리눅스 개발 철학을 이해하는데 필수적이며 다른 운영체제에서
136	    리눅스로 전향하는 사람들에게는 매우 중요하다.
137	
138	
139	  Documentation/SecurityBugs
140	    여러분들이 리눅스 커널의 보안 문제를 발견했다고 생각한다면 이 문서에
141	    나온 단계에 따라서 커널 개발자들에게 알리고 그 문제를 해결할 수 있도록
142	    도와 달라.
143	
144	  Documentation/ManagementStyle
145	    이 문서는 리눅스 커널 메인테이너들이 그들의 방법론에 녹아 있는
146	    정신을 어떻게 공유하고 운영하는지를 설명한다. 이것은 커널 개발에 입문하는
147	    모든 사람들(또는 커널 개발에 작은 호기심이라도 있는 사람들)이
148	    읽어야 할 중요한 문서이다. 왜냐하면 이 문서는 커널 메인테이너들의
149	    독특한 행동에 관하여 흔히 있는 오해들과 혼란들을 해소하고 있기
150	    때문이다.
151	
152	  Documentation/stable_kernel_rules.txt
153	    이 문서는 안정적인 커널 배포가 이루어지는 규칙을 설명하고 있으며
154	    여러분들이 이러한 배포들 중 하나에 변경을 하길 원한다면
155	    무엇을 해야 하는지를 설명한다.
156	
157	  Documentation/kernel-docs.txt
158	    커널 개발에 관계된 외부 문서의 리스트이다. 커널 내의 포함된 문서들
159	    중에 여러분이 찾고 싶은 문서를 발견하지 못할 경우 이 리스트를
160	    살펴보라.
161	
162	  Documentation/applying-patches.txt
163	    패치가 무엇이며 그것을 커널의 다른 개발 브랜치들에 어떻게
164	    적용하는지에 관하여 자세히 설명하고 있는 좋은 입문서이다.
165	
166	커널은 소스 코드 그 자체에서 자동적으로 만들어질 수 있는 많은 문서들을
167	가지고 있다. 이것은 커널 내의 API에 대한 모든 설명, 그리고 락킹을
168	올바르게 처리하는 법에 관한 규칙을 포함하고 있다. 이 문서는
169	Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, HTML,
170	그리고 man 페이지들로 다음과 같이 실행하여 만들어 진다.
171	         make pdfdocs
172	         make psdocs
173	         make htmldocs
174	         make mandocs
175	각각의 명령을 메인 커널 소스 디렉토리로부터 실행한다.
176	
177	
178	커널 개발자가 되는 것
179	---------------------
180	
181	여러분이 리눅스 커널 개발에 관하여 아무것도 모른다면 Linux KernelNewbies
182	프로젝트를 봐야 한다.
183	    http://kernelnewbies.org
184	그곳은 거의 모든 종류의 기본적인 커널 개발 질문들(질문하기 전에 먼저
185	아카이브를 찾아봐라. 과거에 이미 답변되었을 수도 있다)을 할 수 있는 도움이
186	될만한 메일링 리스트가 있다. 또한 실시간으로 질문 할 수 있는 IRC 채널도
187	가지고 있으며 리눅스 커널 개발을 배우는 데 유용한 문서들을 보유하고 있다.
188	
189	웹사이트는 코드구성, 서브시스템들, 그리고 현재 프로젝트들
190	(트리 내, 외부에 존재하는)에 관한 기본적인 정보들을 가지고 있다. 또한
191	그곳은 커널 컴파일이나 패치를 하는 법과 같은 기본적인 것들을  설명한다.
192	
193	여러분이 어디서 시작해야 할진 모르지만 커널 개발 커뮤니티에 참여할 수
194	있는 일들을 찾길 원한다면 리눅스 커널 Janitor 프로젝트를 살펴봐라.
195		http://kernelnewbies.org/KernelJanitors
196	그곳은 시작하기에 훌륭한 장소이다. 그곳은 리눅스 커널 소스 트리내에
197	간단히 정리되고 수정될 수 있는 문제들에 관하여 설명한다. 여러분은 이
198	프로젝트를 대표하는 개발자들과 일하면서 자신의 패치를 리눅스 커널 트리에
199	반영하기 위한 기본적인 것들을 배우게 될것이며 여러분이 아직 아이디어를
200	가지고 있지 않다면 다음에 무엇을 해야할지에 관한 방향을 배울 수 있을
201	것이다.
202	
203	여러분들이 이미 커널 트리에 반영하길 원하는 코드 묶음을 가지고 있지만
204	올바른 포맷으로 포장하는데 도움이 필요하다면 그러한 문제를 돕기 위해
205	만들어진 kernel-mentors 프로젝트가 있다. 그곳은 메일링 리스트이며
206	다음에서 참조할 수 있다.
207	         http://selenic.com/mailman/listinfo/kernel-mentors
208	
209	리눅스 커널 코드에 실제 변경을 하기 전에 반드시 그 코드가 어떻게
210	동작하는지 이해하고 있어야 한다. 코드를 분석하기 위하여 특정한 툴의
211	도움을 빌려서라도 코드를 직접 읽는 것보다 좋은 것은 없다(대부분의
212	자잘한 부분들은 잘 코멘트되어 있다). 그런 툴들 중에 특히 추천할만한
213	것은 Linux Cross-Reference project이며 그것은 자기 참조 방식이며
214	소스코드를 인덱스된 웹 페이지들의 형태로 보여준다. 최신의 멋진 커널
215	코드 저장소는 다음을 통하여 참조할 수 있다.
216	      http://lxr.linux.no/+trees
217	
218	
219	개발 프로세스
220	-------------
221	
222	리눅스 커널 개발 프로세스는 현재 몇몇 다른 메인 커널 "브랜치들"과
223	서브시스템에 특화된 커널 브랜치들로 구성된다. 몇몇 다른 메인
224	브랜치들은 다음과 같다.
225	  - main 3.x 커널 트리
226	  - 3.x.y - 안정된 커널 트리
227	  - 3.x -git 커널 패치들
228	  - 서브시스템을 위한 커널 트리들과 패치들
229	  - 3.x - 통합 테스트를 위한 next 커널 트리
230	
231	3.x 커널 트리
232	---------------
233	
234	3.x 커널들은 Linux Torvalds가 관리하며 kernel.org의 pub/linux/kernel/v3.x/
235	디렉토리에서 참조될 수 있다.개발 프로세스는 다음과 같다.
236	  - 새로운 커널이 배포되자마자 2주의 시간이 주어진다. 이 기간동은
237	    메인테이너들은 큰 diff들을 Linus에게 제출할 수 있다. 대개 이 패치들은
238	    몇 주 동안 -next 커널내에 이미 있었던 것들이다. 큰 변경들을 제출하는 데
239	    선호되는 방법은  git(커널의 소스 관리 툴, 더 많은 정보들은 http://git.or.cz/
240	    에서 참조할 수 있다)를 사용하는 것이지만 순수한 패치파일의 형식으로 보내는
241	    것도 무관하다.
242	  - 2주 후에 -rc1 커널이 배포되며 지금부터는 전체 커널의 안정성에 영향을
243	    미칠수 있는 새로운 기능들을 포함하지 않는 패치들만이 추가될 수 있다.
244	    완전히 새로운 드라이버(혹은 파일시스템)는 -rc1 이후에만 받아들여진다는
245	    것을 기억해라. 왜냐하면 변경이 자체내에서만 발생하고 추가된 코드가
246	    드라이버 외부의 다른 부분에는 영향을 주지 않으므로 그런 변경은
247	    회귀(역자주: 이전에는 존재하지 않았지만 새로운 기능추가나 변경으로 인해
248	    생겨난 버그)를 일으킬 만한 위험을 가지고 있지 않기 때문이다. -rc1이
249	    배포된 이후에 git를 사용하여 패치들을 Linus에게 보낼수 있지만 패치들은
250	    공식적인 메일링 리스트로 보내서 검토를 받을 필요가 있다.
251	  - 새로운 -rc는 Linus가 현재 git tree가 테스트 하기에 충분히 안정된 상태에
252	    있다고 판단될 때마다 배포된다. 목표는 새로운 -rc 커널을 매주 배포하는
253	    것이다.
254	  - 이러한 프로세스는 커널이 "준비(ready)"되었다고 여겨질때까지 계속된다.
255	    프로세스는 대체로 6주간 지속된다.
256	  - 각 -rc 배포에 있는 알려진 회귀의 목록들은 다음 URI에 남겨진다.
257	    http://kernelnewbies.org/known_regressions
258	
259	커널 배포에 있어서 언급할만한 가치가 있는 리눅스 커널 메일링 리스트의
260	Andrew Morton의 글이 있다.
261	        "커널이 언제 배포될지는 아무도 모른다. 왜냐하면 배포는 알려진
262	         버그의 상황에 따라 배포되는 것이지 미리정해 놓은 시간에 따라
263	         배포되는 것은 아니기 때문이다."
264	
265	3.x.y - 안정 커널 트리
266	------------------------
267	
268	3 자리 숫자로 이루어진 버젼의 커널들은 -stable 커널들이다. 그것들은 3.x
269	커널에서 발견된 큰 회귀들이나 보안 문제들 중 비교적 작고 중요한 수정들을
270	포함한다.
271	
272	이것은 가장 최근의 안정적인 커널을 원하는 사용자에게 추천되는 브랜치이며,
273	개발/실험적 버젼을 테스트하는 것을 돕고자 하는 사용자들과는 별로 관련이 없다.
274	
275	어떤 3.x.y 커널도 사용할 수 없다면 그때는 가장 높은 숫자의 3.x
276	커널이 현재의 안정 커널이다.
277	
278	3.x.y는 "stable" 팀<stable@vger.kernel.org>에 의해 관리되며 거의 매번 격주로
279	배포된다.
280	
281	커널 트리 문서들 내에 Documentation/stable_kernel_rules.txt 파일은 어떤
282	종류의 변경들이 -stable 트리로 들어왔는지와 배포 프로세스가 어떻게
283	진행되는지를 설명한다.
284	
285	
286	3.x -git 패치들
287	------------------
288	git 저장소(그러므로 -git이라는 이름이 붙음)에는 날마다 관리되는 Linus의
289	커널 트리의 snapshot 들이 있다. 이 패치들은 일반적으로 날마다 배포되며
290	Linus의 트리의 현재 상태를 나타낸다. 이 패치들은 정상적인지 조금도
291	살펴보지 않고 자동적으로 생성된 것이므로 -rc 커널들 보다도 더 실험적이다.
292	
293	서브시스템 커널 트리들과 패치들
294	-------------------------------
295	다양한 커널 서브시스템의 메인테이너들 --- 그리고 많은 커널 서브시스템 개발자들
296	--- 은 그들의 현재 개발 상태를 소스 저장소로 노출한다. 이를 통해 다른 사람들도
297	커널의 다른 영역에 어떤 변화가 이루어지고 있는지 알 수 있다. 급속히 개발이
298	진행되는 영역이 있고 그렇지 않은 영역이 있으므로, 개발자는 다른 개발자가 제출한
299	수정 사항과 자신의 수정사항의 충돌이나 동일한 일을 동시에 두사람이 따로
300	진행하는 사태를 방지하기 위해 급속히 개발이 진행되고 있는 영역에 작업의
301	베이스를 맞춰줄 것이 요구된다.
302	
303	대부분의 이러한 저장소는 git 트리지만, git이 아닌 SCM으로 관리되거나, quilt
304	시리즈로 제공되는 패치들도 존재한다. 이러한 서브시스템 저장소들은 MAINTAINERS
305	파일에 나열되어 있다. 대부분은 http://git.kernel.org 에서 볼 수 있다.
306	
307	제안된 패치는 서브시스템 트리에 커밋되기 전에 메일링 리스트를 통해
308	리뷰된다(아래의 관련 섹션을 참고하기 바란다). 일부 커널 서브시스템의 경우, 이
309	리뷰 프로세스는 patchwork라는 도구를 통해 추적된다. patchwork은 등록된 패치와
310	패치에 대한 코멘트, 패치의 버전을 볼 수 있는 웹 인터페이스를 제공하고,
311	메인테이너는 패치를 리뷰 중, 리뷰 통과, 또는 반려됨으로 표시할 수 있다.
312	대부분의 이러한 patchwork 사이트는 http://patchwork.kernel.org/ 또는
313	http://patchwork.ozlabs.org/ 에 나열되어 있다.
314	
315	3.x - 통합 테스트를 위한 next 커널 트리
316	-----------------------------------------
317	서브시스템 트리들의 변경사항들은 mainline 3.x 트리로 들어오기 전에 통합
318	테스트를 거쳐야 한다. 이런 목적으로, 모든 서브시스템 트리의 변경사항을 거의
319	매일 받아가는 특수한 테스트 저장소가 존재한다:
320	       http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git
321	       http://linux.f-seidel.de/linux-next/pmwiki/
322	
323	이런 식으로, -next 커널을 통해 다음 머지 기간에 메인라인 커널에 어떤 변경이
324	가해질 것인지 간략히 알 수 있다. 모험심 강한 테스터라면 -next 커널에서 테스트를
325	수행하는 것도 좋을 것이다.
326	
327	버그 보고
328	---------
329	bugzilla.kernel.org는 리눅스 커널 개발자들이 커널의 버그를 추적하는 곳이다.
330	사용자들은 발견한 모든 버그들을 보고하기 위하여 이 툴을 사용할 것을 권장한다.
331	kernel bugzilla를 사용하는 자세한 방법은 다음을 참조하라.
332	    http://test.kernel.org/bugzilla/faq.html
333	
334	메인 커널 소스 디렉토리에 있는 REPORTING-BUGS 파일은 커널 버그라고 생각되는
335	것을 보고하는 방법에 관한 좋은 템플릿이며 문제를 추적하기 위해서 커널
336	개발자들이 필요로 하는 정보가 무엇들인지를 상세히 설명하고 있다.
337	
338	
339	버그 리포트들의 관리
340	--------------------
341	
342	여러분의 해킹 기술을 연습하는 가장 좋은 방법 중의 하는 다른 사람들이
343	보고한 버그들을 수정하는 것이다. 여러분은 커널을 더욱 안정화시키는데
344	도움을 줄 뿐만이 아니라 실제있는 문제들을 수정하는 법을 배우게 되고
345	그와 함께 여러분들의 기술은 향상될 것이며 다른 개발자들이 여러분의
346	존재에 대해 알게 될 것이다. 버그를 수정하는 것은 개발자들  사이에서
347	점수를 얻을 수 있는 가장 좋은 방법중의 하나이다. 왜냐하면 많은 사람들은
348	다른 사람들의 버그들을 수정하기 위하여 시간을 낭비하지 않기 때문이다.
349	
350	이미 보고된 버그 리포트들을 가지고 작업하기 위해서 http://bugzilla.kernel.org351	참조하라. 여러분이 앞으로 생겨날 버그 리포트들의 조언자가 되길 원한다면
352	bugme-new 메일링 리스트나(새로운 버그 리포트들만이 이곳에서 메일로 전해진다)
353	bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메일로 전해진다)
354	에 등록하면 된다.
355	
356	      https://lists.linux-foundation.org/mailman/listinfo/bugme-new
357	      https://lists.linux-foundation.org/mailman/listinfo/bugme-janitors
358	
359	
360	
361	메일링 리스트들
362	---------------
363	
364	위의 몇몇 문서들이 설명하였지만 핵심 커널 개발자들의 대다수는
365	리눅스 커널 메일링 리스트에 참여하고 있다. 리스트에 등록하고 해지하는
366	방법에 관한 자세한 사항은 다음에서 참조할 수 있다.
367	    http://vger.kernel.org/vger-lists.html#linux-kernel
368	웹상의 많은 다른 곳에도 메일링 리스트의 아카이브들이 있다.
369	이러한 아카이브들을 찾으려면 검색 엔진을 사용하라. 예를 들어:
370	      http://dir.gmane.org/gmane.linux.kernel
371	여러분이 새로운 문제에 관해 리스트에 올리기 전에 말하고 싶은 주제에 관한
372	것을 아카이브에서 먼저 찾아보기를 강력히 권장한다. 이미 상세하게 토론된 많은
373	것들이 메일링 리스트의 아카이브에 기록되어 있다.
374	
375	각각의 커널 서브시스템들의 대부분은 자신들의 개발에 관한 노력들로 이루어진
376	분리된 메일링 리스트를 따로 가지고 있다. 다른 그룹들이 무슨 리스트를 가지고
377	있는지는 MAINTAINERS 파일을 참조하라.
378	
379	많은 리스트들은 kernel.org에서 호스트되고 있다. 그 정보들은 다음에서 참조될 수 있다.
380	         http://vger.kernel.org/vger-lists.html
381	
382	리스트들을 사용할 때는 올바른 예절을 따를 것을 유념해라.
383	대단하진 않지만 다음 URL은 리스트(혹은 모든 리스트)와 대화하는 몇몇 간단한
384	가이드라인을 가지고 있다.
385	         http://www.albion.com/netiquette/
386	
387	여러 사람들이 여러분의 메일에 응답한다면 CC: 즉 수신 리스트는 꽤 커지게
388	될 것이다. 아무 이유없이 CC에서 어떤 사람도 제거하거나 리스트 주소로만
389	회신하지 마라. 메일을 보낸 사람으로서 하나를 받고 리스트로부터 또
390	하나를 받아 두번 받는 것에 익숙하여 있으니 mail-header를 조작하려고 하지
391	말아라. 사람들은 그런 것을 좋아하지 않을 것이다.
392	
393	여러분의 회신의 문맥을 원래대로 유지해야 한다. 여러분들의 회신의 윗부분에
394	"John 커널해커는 작성했다...."를 유지하며 여러분들의 의견을 그 메일의 윗부분에
395	작성하지 말고 각 인용한 단락들 사이에 넣어라.
396	
397	여러분들이 패치들을 메일에 넣는다면 그것들은 Documentation/SubmittingPatches에
398	나와있는데로 명백히(plain) 읽을 수 있는 텍스트여야 한다. 커널 개발자들은
399	첨부파일이나 압축된 패치들을 원하지 않는다. 그들은 여러분들의 패치의
400	각 라인 단위로 코멘트를 하길 원하며 압축하거나 첨부하지 않고 보내는 것이
401	그렇게 할 수 있는 유일한 방법이다. 여러분들이 사용하는 메일 프로그램이
402	스페이스나 탭 문자들을 조작하지 않는지 확인하라. 가장 좋은 첫 테스트는
403	메일을 자신에게 보내보고 스스로 그 패치를 적용해보라. 그것이 동작하지
404	않는다면 여러분의 메일 프로그램을 고치던가 제대로 동작하는 프로그램으로
405	바꾸어라.
406	
407	무엇보다도 메일링 리스트의 다른 구독자들에게 보여주려 한다는 것을 기억하라.
408	
409	
410	커뮤니티와 협력하는 법
411	--------------------
412	
413	커널 커뮤니티의 목적은 가능한한 가장 좋은 커널을 제공하는 것이다. 여러분이
414	받아들여질 패치를 제출하게 되면 그 패치의 기술적인 이점으로 검토될 것이다.
415	그럼 여러분들은 무엇을 기대하고 있어야 하는가?
416	 - 비판
417	 - 의견
418	 - 변경을 위한 요구
419	 - 당위성을 위한 요구
420	 - 침묵
421	
422	기억하라. 이것들은 여러분의 패치가 커널로 들어가기 위한 과정이다. 여러분의
423	패치들은 비판과 다른 의견을 받을 수 있고 그것들을 기술적인 레벨로 평가하고
424	재작업하거나 또는 왜 수정하면 안되는지에 관하여 명료하고 간결한 이유를
425	말할 수 있어야 한다. 여러분이 제출한 것에 어떤 응답도 있지 않다면 몇 일을
426	기다려보고 다시 시도해라. 때론 너무 많은 메일들 속에 묻혀버리기도 한다.
427	
428	여러분은 무엇을 해서는 안되는가?
429	 - 여러분의 패치가 아무 질문 없이 받아들여지기를 기대하는 것
430	 - 방어적이 되는 것
431	 - 의견을 무시하는 것
432	 - 요청된 변경을 하지 않고 패치를 다시 제출하는 것
433	
434	가능한한 가장 좋은 기술적인 해답을 찾고 있는 커뮤니티에서는 항상
435	어떤 패치가 얼마나 좋은지에 관하여 다른 의견들이 있을 수 있다. 여러분은
436	협조적이어야 하고 기꺼이 여러분의 생각을 커널 내에 맞추어야 한다. 아니면
437	적어도 여러분의 것이 가치있다는 것을 증명하여야 한다. 잘못된 것도 여러분이
438	올바른 방향의 해결책으로 이끌어갈 의지가 있다면 받아들여질 것이라는 점을
439	기억하라.
440	
441	여러분의 첫 패치에 여러분이 수정해야하는 십여개 정도의 회신이 오는
442	경우도 흔하다. 이것은 여러분의 패치가 받아들여지지 않을 것이라는 것을
443	의미하는 것이 아니고 개인적으로 여러분에게 감정이 있어서 그러는 것도
444	아니다. 간단히 여러분의 패치에 제기된 문제들을 수정하고 그것을 다시
445	보내라.
446	
447	
448	커널 커뮤니티와 기업 조직간의 차이점
449	-----------------------------------------------------------------
450	커널 커뮤니티는 가장 전통적인 회사의 개발 환경과는 다르다. 여기에 여러분들의
451	문제를 피하기 위한 목록이 있다.
452	  여러분들이 제안한 변경들에 관하여 말할 때 좋은 것들 :
453	    - "이것은 여러 문제들을 해결합니다."
454	    - "이것은 2000 라인의 코드를 줄입니다."
455	    - "이것은 내가 말하려는 것에 관해 설명하는 패치입니다."
456	    - "나는 5개의 다른 아키텍쳐에서 그것을 테스트 했으므로..."
457	    - "여기에 일련의 작은 패치들이 있으므로..."
458	    - "이것은 일반적인 머신에서 성능을 향상함으로..."
459	
460	  여러분들이 말할 때 피해야 할 좋지 않은 것들 :
461	    - "우리는 그것을 AIX/ptx/Solaris에서 이러한 방법으로 했다. 그러므로 그것은 좋은 것임에 틀림없다..."
462	    - "나는 20년동안 이것을 해왔다. 그러므로..."
463	    - "이것은 돈을 벌기위해 나의 회사가 필요로 하는 것이다."
464	    - "이것은 우리의 엔터프라이즈 상품 라인을 위한 것이다."
465	    - "여기에 나의 생각을 말하고 있는 1000 페이지 설계 문서가 있다."
466	    - "나는 6달동안 이것을 했으니..."
467	    - "여기에 5000 라인 짜리 패치가 있으니..."
468	    - "나는 현재 뒤죽박죽인 것을 재작성했다. 그리고 여기에..."
469	    - "나는 마감시한을 가지고 있으므로 이 패치는 지금 적용될 필요가 있다."
470	
471	커널 커뮤니티가 전통적인 소프트웨어 엔지니어링 개발 환경들과
472	또 다른 점은 얼굴을 보지 않고 일한다는 점이다. 이메일과 irc를 대화의
473	주요수단으로 사용하는 것의 한가지 장점은 성별이나 인종의 차별이
474	없다는 것이다. 리눅스 커널의 작업 환경에서는 단지 이메일 주소만
475	알수 있기 때문에 여성과 소수 민족들도 모두 받아들여진다. 국제적으로
476	일하게 되는 측면은 사람의 이름에 근거하여 성별을 추측할 수 없게
477	하기때문에 차별을 없애는 데 도움을 준다. Andrea라는 이름을 가진 남자와
478	Pat이라는 이름을 가진 여자가 있을 수도 있는 것이다. 리눅스 커널에서
479	작업하며 생각을 표현해왔던 대부분의 여성들은 긍정적인 경험을 가지고
480	있다.
481	
482	언어 장벽은 영어에 익숙하지 않은 몇몇 사람들에게 문제가 될 수도 있다.
483	언어의 훌륭한 구사는 메일링 리스트에서 올바르게 자신의 생각을
484	표현하기 위하여 필요하다. 그래서 여러분은 이메일을 보내기 전에
485	영어를 올바르게 사용하고 있는지를 체크하는 것이 바람직하다.
486	
487	
488	여러분의 변경을 나누어라
489	------------------------
490	
491	리눅스 커널 커뮤니티는 한꺼번에 굉장히 큰 코드의 묶음(chunk)을 쉽게
492	받아들이지 않는다. 변경은 적절하게 소개되고, 검토되고, 각각의
493	부분으로 작게 나누어져야 한다. 이것은 회사에서 하는 것과는 정확히
494	반대되는 것이다. 여러분들의 제안은 개발 초기에 일찍이 소개되야 한다.
495	그래서 여러분들은 자신이 하고 있는 것에 관하여 피드백을 받을 수 있게
496	된다. 커뮤니티가 여러분들이 커뮤니티와 함께 일하고 있다는 것을
497	느끼도록 만들고 커뮤니티가 여러분의 기능을 위한 쓰레기 장으로써
498	사용되지 않고 있다는 것을 느끼게 하자. 그러나 메일링 리스트에 한번에
499	50개의 이메일을 보내지는 말아라. 여러분들의 일련의 패치들은 항상
500	더 작아야 한다.
501	
502	패치를 나누는 이유는 다음과 같다.
503	
504	1) 작은 패치들은 여러분의 패치들이 적용될 수 있는 확률을 높여준다.
505	   왜냐하면 다른 사람들은 정확성을 검증하기 위하여 많은 시간과 노력을
506	   들이기를 원하지 않는다. 5줄의 패치는 메인테이너가 거의 몇 초간 힐끗
507	   보면 적용될 수 있다. 그러나 500 줄의 패치는 정확성을 검토하기 위하여
508	   몇시간이 걸릴 수도 있다(걸리는 시간은 패치의 크기 혹은 다른 것에
509	   비례하여 기하급수적으로 늘어난다).
510	
511	   패치를 작게 만드는 것은 무엇인가 잘못되었을 때 디버그하는 것을
512	   쉽게 만든다. 즉, 그렇게 만드는 것은 매우 큰 패치를 적용한 후에
513	   조사하는 것 보다 작은 패치를 적용한 후에 (그리고 몇몇의 것이
514	   깨졌을 때) 하나씩 패치들을 제거해가며 디버그 하기 쉽도록 만들어 준다.
515	
516	2) 작은 패치들을 보내는 것뿐만 아니라 패치들을 제출하기전에 재작성하고
517	   간단하게(혹은 간단한게 재배치하여) 하는 것도 중요하다.
518	
519	여기에 커널 개발자 Al Viro의 이야기가 있다.
520	    "학생의 수학 숙제를 채점하는 선생님을 생각해보라. 선생님은 학생들이
521	    답을 얻을때까지 겪은 시행착오를 보길 원하지 않는다. 선생님들은
522	    간결하고 가장 뛰어난 답을 보길 원한다. 훌륭한 학생은 이것을 알고
523	    마지막으로 답을 얻기 전 중간 과정들을 제출하진 않는다.
524	
525	    커널 개발도 마찬가지이다. 메인테이너들과 검토하는 사람들은 문제를
526	    풀어나가는 과정속에 숨겨진 과정을 보길 원하진 않는다. 그들은
527	    간결하고 멋진 답을 보길 원한다."
528	
529	커뮤니티와 협력하며 뛰어난 답을 찾는 것과 여러분들의 끝마치지 못한 작업들
530	사이에 균형을 유지해야 하는 것은 어려울지도 모른다. 그러므로 프로세스의
531	초반에 여러분의 작업을 향상시키기위한 피드백을 얻는 것 뿐만 아니라
532	여러분들의 변경들을 작은 묶음으로 유지해서 심지어는 여러분의 작업의
533	모든 부분이 지금은 포함될 준비가 되어있지 않지만 작은 부분은 벌써
534	받아들여질 수 있도록 유지하는 것이 바람직하다.
535	
536	또한 완성되지 않았고 "나중에 수정될 것이다." 와 같은 것들을 포함하는
537	패치들은 받아들여지지 않을 것이라는 점을 유념하라.
538	
539	
540	변경을 정당화해라
541	-----------------
542	
543	여러분들의 나누어진 패치들을 리눅스 커뮤니티가 왜 반영해야 하는지를
544	알도록 하는 것은 매우 중요하다. 새로운 기능들이 필요하고 유용하다는
545	것은 반드시 그에 합당한 이유가 있어야 한다.
546	
547	
548	변경을 문서화해라
549	-----------------
550	
551	여러분이 패치를 보내려 할때는 여러분이 무엇을 말하려고 하는지를 충분히
552	생각하여 이메일을 작성해야 한다. 이 정보는 패치를 위한 ChangeLog가 될
553	것이다. 그리고 항상 그 내용을 보길 원하는 모든 사람들을 위해 보존될
554	것이다. 패치는 완벽하게 다음과 같은 내용들을 포함하여 설명해야 한다.
555	  - 변경이 왜 필요한지
556	  - 패치에 관한 전체 설계 접근(approach)
557	  - 구현 상세들
558	  - 테스트 결과들
559	
560	이것이 무엇인지 더 자세한 것을 알고 싶다면 다음 문서의 ChageLog 항을 봐라.
561	   "The Perfect Patch"
562	    http://www.ozlabs.org/~akpm/stuff/tpp.txt
563	
564	
565	
566	
567	이 모든 것을 하는 것은 매우 어려운 일이다. 완벽히 소화하는 데는 적어도 몇년이
568	걸릴 수도 있다. 많은 인내와 결심이 필요한 계속되는 개선의 과정이다. 그러나
569	가능한한 포기하지 말라. 많은 사람들은 이전부터 해왔던 것이고 그 사람들도
570	정확하게 여러분들이 지금 서 있는 그 곳부터  시작했었다.
571	
572	
573	
574	
575	----------
576	"개발 프로세스"(http://lwn.net/Articles/94386/) 섹션을
577	작성하는데 있어 참고할 문서를 사용하도록 허락해준 Paolo Ciarrocchi에게
578	감사한다. 여러분들이 말해야 할 것과 말해서는 안되는 것의 목록 중 일부를 제공해준
579	Randy Dunlap과 Gerrit Huizenga에게 감사한다. 또한 검토와 의견 그리고
580	공헌을 아끼지 않은 Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers,
581	Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton, Andi Kleen,
582	Vadim Lobanov, Jesper Juhl, Adrian Bunk, Keri Harris, Frans Pop,
583	David A. Wheeler, Junio Hamano, Michael Kerrisk, and Alex Shepard에게도 감사를 전한다.
584	그들의 도움이 없었다면 이 문서는 존재하지 않았을 것이다.
585	
586	
587	
588	메인테이너: Greg Kroah-Hartman <greg@kroah.com>
Hide Line Numbers
About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Information is copyright its respective author. All material is available from the Linux Kernel Source distributed under a GPL License. This page is provided as a free service by mjmwired.net.