aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/DocBook/deviceiobook.tmpl3
-rw-r--r--Documentation/HOWTO4
-rw-r--r--Documentation/SubmittingPatches2
-rw-r--r--Documentation/accounting/getdelays.c2
-rw-r--r--Documentation/dvb/get_dvb_firmware24
-rw-r--r--Documentation/filesystems/9p.txt24
-rw-r--r--Documentation/ko_KR/HOWTO623
-rw-r--r--Documentation/vm/numa_memory_policy.txt332
-rw-r--r--Documentation/watchdog/00-INDEX10
9 files changed, 1002 insertions, 22 deletions
diff --git a/Documentation/DocBook/deviceiobook.tmpl b/Documentation/DocBook/deviceiobook.tmpl
index 90ed23df1f68..c917de681ccd 100644
--- a/Documentation/DocBook/deviceiobook.tmpl
+++ b/Documentation/DocBook/deviceiobook.tmpl
@@ -316,7 +316,8 @@ CPU B: spin_unlock_irqrestore(&dev_lock, flags)
316 316
317 <chapter id="pubfunctions"> 317 <chapter id="pubfunctions">
318 <title>Public Functions Provided</title> 318 <title>Public Functions Provided</title>
319!Einclude/asm-i386/io.h 319!Iinclude/asm-i386/io.h
320!Elib/iomap.c
320 </chapter> 321 </chapter>
321 322
322</book> 323</book>
diff --git a/Documentation/HOWTO b/Documentation/HOWTO
index f8cc3f8ed152..c64e969dc33b 100644
--- a/Documentation/HOWTO
+++ b/Documentation/HOWTO
@@ -208,7 +208,7 @@ tools. One such tool that is particularly recommended is the Linux
208Cross-Reference project, which is able to present source code in a 208Cross-Reference project, which is able to present source code in a
209self-referential, indexed webpage format. An excellent up-to-date 209self-referential, indexed webpage format. An excellent up-to-date
210repository of the kernel code may be found at: 210repository of the kernel code may be found at:
211 http://sosdg.org/~coywolf/lxr/ 211 http://users.sosdg.org/~qiyong/lxr/
212 212
213 213
214The development process 214The development process
@@ -384,7 +384,7 @@ One of the best ways to put into practice your hacking skills is by fixing
384bugs reported by other people. Not only you will help to make the kernel 384bugs reported by other people. Not only you will help to make the kernel
385more stable, you'll learn to fix real world problems and you will improve 385more stable, you'll learn to fix real world problems and you will improve
386your skills, and other developers will be aware of your presence. Fixing 386your skills, and other developers will be aware of your presence. Fixing
387bugs is one of the best ways to earn merit amongst the developers, because 387bugs is one of the best ways to get merits among other developers, because
388not many people like wasting time fixing other people's bugs. 388not many people like wasting time fixing other people's bugs.
389 389
390To work in the already reported bug reports, go to http://bugzilla.kernel.org. 390To work in the already reported bug reports, go to http://bugzilla.kernel.org.
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index d6b45a9b29b4..397575880dc4 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -560,7 +560,7 @@ NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!
560 <http://marc.theaimsgroup.com/?l=linux-kernel&m=112112749912944&w=2> 560 <http://marc.theaimsgroup.com/?l=linux-kernel&m=112112749912944&w=2>
561 561
562Kernel Documentation/CodingStyle: 562Kernel Documentation/CodingStyle:
563 <http://sosdg.org/~coywolf/lxr/source/Documentation/CodingStyle> 563 <http://users.sosdg.org/~qiyong/lxr/source/Documentation/CodingStyle>
564 564
565Linus Torvalds's mail on the canonical patch format: 565Linus Torvalds's mail on the canonical patch format:
566 <http://lkml.org/lkml/2005/4/7/183> 566 <http://lkml.org/lkml/2005/4/7/183>
diff --git a/Documentation/accounting/getdelays.c b/Documentation/accounting/getdelays.c
index 24c5aade8998..cbee3a27f768 100644
--- a/Documentation/accounting/getdelays.c
+++ b/Documentation/accounting/getdelays.c
@@ -196,7 +196,7 @@ void print_delayacct(struct taskstats *t)
196 "IO %15s%15s\n" 196 "IO %15s%15s\n"
197 " %15llu%15llu\n" 197 " %15llu%15llu\n"
198 "MEM %15s%15s\n" 198 "MEM %15s%15s\n"
199 " %15llu%15llu\n" 199 " %15llu%15llu\n",
200 "count", "real total", "virtual total", "delay total", 200 "count", "real total", "virtual total", "delay total",
201 t->cpu_count, t->cpu_run_real_total, t->cpu_run_virtual_total, 201 t->cpu_count, t->cpu_run_real_total, t->cpu_run_virtual_total,
202 t->cpu_delay_total, 202 t->cpu_delay_total,
diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware
index b4d306ae9234..f2e908d7f90d 100644
--- a/Documentation/dvb/get_dvb_firmware
+++ b/Documentation/dvb/get_dvb_firmware
@@ -111,21 +111,21 @@ sub tda10045 {
111} 111}
112 112
113sub tda10046 { 113sub tda10046 {
114 my $sourcefile = "tt_budget_217g.zip"; 114 my $sourcefile = "TT_PCI_2.19h_28_11_2006.zip";
115 my $url = "http://www.technotrend.de/new/217g/$sourcefile"; 115 my $url = "http://technotrend-online.com/download/software/219/$sourcefile";
116 my $hash = "6a7e1e2f2644b162ff0502367553c72d"; 116 my $hash = "6a7e1e2f2644b162ff0502367553c72d";
117 my $outfile = "dvb-fe-tda10046.fw"; 117 my $outfile = "dvb-fe-tda10046.fw";
118 my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1); 118 my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1);
119 119
120 checkstandard(); 120 checkstandard();
121 121
122 wgetfile($sourcefile, $url); 122 wgetfile($sourcefile, $url);
123 unzip($sourcefile, $tmpdir); 123 unzip($sourcefile, $tmpdir);
124 extract("$tmpdir/software/OEM/PCI/App/ttlcdacc.dll", 0x3f731, 24478, "$tmpdir/fwtmp"); 124 extract("$tmpdir/TT_PCI_2.19h_28_11_2006/software/OEM/PCI/App/ttlcdacc.dll", 0x65389, 24478, "$tmpdir/fwtmp");
125 verify("$tmpdir/fwtmp", $hash); 125 verify("$tmpdir/fwtmp", $hash);
126 copy("$tmpdir/fwtmp", $outfile); 126 copy("$tmpdir/fwtmp", $outfile);
127 127
128 $outfile; 128 $outfile;
129} 129}
130 130
131sub tda10046lifeview { 131sub tda10046lifeview {
diff --git a/Documentation/filesystems/9p.txt b/Documentation/filesystems/9p.txt
index bbd8b28c13de..cda6905cbe49 100644
--- a/Documentation/filesystems/9p.txt
+++ b/Documentation/filesystems/9p.txt
@@ -6,12 +6,26 @@ ABOUT
6 6
7v9fs is a Unix implementation of the Plan 9 9p remote filesystem protocol. 7v9fs is a Unix implementation of the Plan 9 9p remote filesystem protocol.
8 8
9This software was originally developed by Ron Minnich <rminnich@lanl.gov> 9This software was originally developed by Ron Minnich <rminnich@sandia.gov>
10and Maya Gokhale <maya@lanl.gov>. Additional development by Greg Watson 10and Maya Gokhale. Additional development by Greg Watson
11<gwatson@lanl.gov> and most recently Eric Van Hensbergen 11<gwatson@lanl.gov> and most recently Eric Van Hensbergen
12<ericvh@gmail.com>, Latchesar Ionkov <lucho@ionkov.net> and Russ Cox 12<ericvh@gmail.com>, Latchesar Ionkov <lucho@ionkov.net> and Russ Cox
13<rsc@swtch.com>. 13<rsc@swtch.com>.
14 14
15The best detailed explanation of the Linux implementation and applications of
16the 9p client is available in the form of a USENIX paper:
17 http://www.usenix.org/events/usenix05/tech/freenix/hensbergen.html
18
19Other applications are described in the following papers:
20 * XCPU & Clustering
21 http://www.xcpu.org/xcpu-talk.pdf
22 * KVMFS: control file system for KVM
23 http://www.xcpu.org/kvmfs.pdf
24 * CellFS: A New ProgrammingModel for the Cell BE
25 http://www.xcpu.org/cellfs-talk.pdf
26 * PROSE I/O: Using 9p to enable Application Partitions
27 http://plan9.escet.urjc.es/iwp9/cready/PROSE_iwp9_2006.pdf
28
15USAGE 29USAGE
16===== 30=====
17 31
@@ -90,9 +104,9 @@ subset of the namespace by extending the path: '#U*'/tmp would just export
90and export. 104and export.
91 105
92A Linux version of the 9p server is now maintained under the npfs project 106A Linux version of the 9p server is now maintained under the npfs project
93on sourceforge (http://sourceforge.net/projects/npfs). There is also a 107on sourceforge (http://sourceforge.net/projects/npfs). The currently
94more stable single-threaded version of the server (named spfs) available from 108maintained version is the single-threaded version of the server (named spfs)
95the same CVS repository. 109available from the same CVS repository.
96 110
97There are user and developer mailing lists available through the v9fs project 111There are user and developer mailing lists available through the v9fs project
98on sourceforge (http://sourceforge.net/projects/v9fs). 112on sourceforge (http://sourceforge.net/projects/v9fs).
diff --git a/Documentation/ko_KR/HOWTO b/Documentation/ko_KR/HOWTO
new file mode 100644
index 000000000000..b51d7ca842ba
--- /dev/null
+++ b/Documentation/ko_KR/HOWTO
@@ -0,0 +1,623 @@
1NOTE:
2This is a version of Documentation/HOWTO translated into korean
3This document is maintained by minchan Kim < minchan.kim@gmail.com>
4If you find any difference between this document and the original file or
5a problem with the translation, please contact the maintainer of this file.
6
7Please also note that the purpose of this file is to be easier to
8read for non English (read: korean) speakers and is not intended as
9a fork. So if you have any comments or updates for this file please
10try to update the original English file first.
11
12==================================
13이 문서는
14Documentation/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
81GPL에 관한 잦은 질문들과 답변들은 다음을 참조하라.
82 http://www.gnu.org/licenses/gpl-faq.html
83
84
85문서
86----
87
88리눅스 커널 소스 트리는 커널 커뮤니티와 일하는 법을 배우기 위한 많은
89귀중한 문서들을 가지고 있다. 새로운 기능들이 커널에 들어가게 될 때,
90그 기능을 어떻게 사용하는지에 관한 설명을 위하여 새로운 문서 파일을
91추가하는 것을 권장한다. 커널이 유저스페이스로 노출하는 인터페이스를
92변경하게 되면 변경을 설명하는 메뉴얼 페이지들에 대한 패치나 정보를
93mtk-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올바르게 처리하는 법에 관한 규칙을 포함하고 있다. 이 문서는
168Documentation/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
2302.6.x 커널 트리
231---------------
232
2332.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커널 배포에 있어서 언급할만한 가치가 있는 리눅스 커널 메일링 리스트의
258Andrew Morton의 글이 있다.
259 "커널이 언제 배포될지는 아무로 모른다. 왜냐하면 배포는 알려진
260 버그의 상황에 따라 배포되는 것이지 미리정해 놓은 시간에 따라
261 배포되는 것은 아니기 때문이다."
262
2632.6.x.y - 안정 커널 트리
264------------------------
265
2664 자리 숫자로 이루어진 버젼의 커널들은 -stable 커널들이다. 그것들은 2.6.x
267커널에서 발견된 큰 퇴보들이나 보안 문제들 중 비교적 작고 중요한 수정들을
268포함한다.
269
270이것은 가장 최근의 안정적인 커널을 원하는 사용자에게 추천되는 브랜치이며,
271개발/실험적 버젼을 테스트하는 것을 돕는데는 별로 관심이 없다.
272
273어떤 2.6.x.y 커널도 사용가능하지 않다면 그때는 가장 높은 숫자의 2.6.x
274커널이 현재의 안정 커널이다.
275
2762.6.x.y는 "stable" 팀<stable@kernel.org>에 의해 관리되며 거의 매번 격주로
277배포된다.
278
279커널 트리 문서들 내에 Documentation/stable_kernel_rules.txt 파일은 어떤
280종류의 변경들이 -stable 트리로 들어왔는지와 배포 프로세스가 어떻게
281진행되는지를 설명한다.
282
283
2842.6.x -git 패치들
285------------------
286git 저장소(그러므로 -git이라는 이름이 붙음)에는 날마다 관리되는 Linus의
287커널 트리의 snapshot 들이 있다. 이 패치들은 일반적으로 날마다 배포되며
288Linus의 트리의 현재 상태를 나타낸다. 이 패치들은 정상적인지 조금도
289살펴보지 않고 자동적으로 생성된 것이므로 -rc 커널들 보다도 더 실험적이다.
290
2912.6.x -mm 커널 패치들
292---------------------
293Andrew 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---------
365bugzilla.kernel.org는 리눅스 커널 개발자들이 커널의 버그를 추적하는 곳이다.
366사용자들은 발견한 모든 버그들을 보고하기 위하여 이 툴을 사용할 것을 권장한다.
367kernel 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참조하라. 여러분이 앞으로 생겨날 버그 리포트들의 조언자가 되길 원한다면
388bugme-new 메일링 리스트나(새로운 버그 리포트들만이 이곳에서 메일로 전해진다)
389bugme-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라는 이름을 가진 남자와
514Pat이라는 이름을 가진 여자가 있을 수도 있는 것이다. 리눅스 커널에서
515작업하며 생각을 표현해왔던 대부분의 여성들은 긍정적인 경험을 가지고
516있다.
517
518언어 장벽은 영어에 익숙하지 않은 몇몇 사람들에게 문제가 될 수도 있다.
519 언어의 훌륭한 구사는 메일링 리스트에서 올바르게 자신의 생각을
520표현하기 위하여 필요하다. 그래서 여러분은 이메일을 보내기 전에
521영어를 올바르게 사용하고 있는지를 체크하는 것이 바람직하다.
522
523
524여러분의 변경을 나누어라
525------------------------
526
527리눅스 커널 커뮤니티는 한꺼번에 굉장히 큰 코드의 묶음을 쉽게
528받아들이지 않는다. 변경은 적절하게 소개되고, 검토되고, 각각의
529부분으로 작게 나누어져야 한다. 이것은 회사에서 하는 것과는 정확히
530반대되는 것이다. 여러분들의 제안은 개발 초기에 일찍이 소개되야 한다.
531그래서 여러분들은 자신이 하고 있는 것에 관하여 피드백을 받을 수 있게
532된다. 커뮤니티가 여러분들이 커뮤니티와 함께 일하고 있다는 것을
533느끼도록 만들고 커뮤니티가 여러분의 기능을 위한 쓰레기 장으로서
534사용되지 않고 있다는 것을 느끼게 하자. 그러나 메일링 리스트에 한번에
53550개의 이메일을 보내지는 말아라. 여러분들의 일련의 패치들은 항상
536더 작아야 한다.
537
538패치를 나누는 이유는 다음과 같다.
539
5401) 작은 패치들은 여러분의 패치들이 적용될 수 있는 확률을 높여준다.
541 왜냐하면 다른 사람들은 정확성을 검증하기 위하여 많은 시간과 노력을
542 들이기를 원하지 않는다. 5줄의 패치는 메인트너가 거의 몇 초간 힐끗
543 보면 적용될 수 있다. 그러나 500 줄의 패치는 정확성을 검토하기 위하여
544 몇시간이 걸릴 수도 있다(걸리는 시간은 패치의 크기 혹은 다른 것에
545 비례하여 기하급수적으로 늘어난다).
546
547 패치를 작게 만드는 것은 무엇인가 잘못되었을 때 디버그하는 것을
548 쉽게 만든다. 즉, 그렇게 만드는 것은 매우 큰 패치를 적용한 후에
549 조사하는 것 보다 작은 패치를 적용한 후에 (그리고 몇몇의 것이
550 깨졌을 때) 하나씩 패치들을 제거해가며 디버그 하기 쉽도록 만들어 준다.
551
5522) 작은 패치들을 보내는 것뿐만 아니라 패치들을 제출하기전에 재작성하고
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감사한다. 여러분들이 말해야 할 것과 말해서는 안되는 것의 목록 중 일부를 제공해준
614Randy Dunlap과 Gerrit Huizenga에게 감사한다. 또한 검토와 의견 그리고
615공헌을 아끼지 않은 Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers,
616Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton, Andi Kleen,
617Vadim Lobanov, Jesper Juhl, Adrian Bunk, Keri Harris, Frans Pop,
618David A. Wheeler, Junio Hamano, Michael Kerrisk, and Alex Shepard에게도 감사를 전한다.
619그들의 도움이 없었다면 이 문서는 존재하지 않았을 것이다.
620
621
622
623메인트너: Greg Kroah-Hartman <greg@kroah.com>
diff --git a/Documentation/vm/numa_memory_policy.txt b/Documentation/vm/numa_memory_policy.txt
new file mode 100644
index 000000000000..8242f52d0f22
--- /dev/null
+++ b/Documentation/vm/numa_memory_policy.txt
@@ -0,0 +1,332 @@
1
2What is Linux Memory Policy?
3
4In the Linux kernel, "memory policy" determines from which node the kernel will
5allocate memory in a NUMA system or in an emulated NUMA system. Linux has
6supported platforms with Non-Uniform Memory Access architectures since 2.4.?.
7The current memory policy support was added to Linux 2.6 around May 2004. This
8document attempts to describe the concepts and APIs of the 2.6 memory policy
9support.
10
11Memory policies should not be confused with cpusets (Documentation/cpusets.txt)
12which is an administrative mechanism for restricting the nodes from which
13memory may be allocated by a set of processes. Memory policies are a
14programming interface that a NUMA-aware application can take advantage of. When
15both cpusets and policies are applied to a task, the restrictions of the cpuset
16takes priority. See "MEMORY POLICIES AND CPUSETS" below for more details.
17
18MEMORY POLICY CONCEPTS
19
20Scope of Memory Policies
21
22The Linux kernel supports _scopes_ of memory policy, described here from
23most general to most specific:
24
25 System Default Policy: this policy is "hard coded" into the kernel. It
26 is the policy that governs all page allocations that aren't controlled
27 by one of the more specific policy scopes discussed below. When the
28 system is "up and running", the system default policy will use "local
29 allocation" described below. However, during boot up, the system
30 default policy will be set to interleave allocations across all nodes
31 with "sufficient" memory, so as not to overload the initial boot node
32 with boot-time allocations.
33
34 Task/Process Policy: this is an optional, per-task policy. When defined
35 for a specific task, this policy controls all page allocations made by or
36 on behalf of the task that aren't controlled by a more specific scope.
37 If a task does not define a task policy, then all page allocations that
38 would have been controlled by the task policy "fall back" to the System
39 Default Policy.
40
41 The task policy applies to the entire address space of a task. Thus,
42 it is inheritable, and indeed is inherited, across both fork()
43 [clone() w/o the CLONE_VM flag] and exec*(). This allows a parent task
44 to establish the task policy for a child task exec()'d from an
45 executable image that has no awareness of memory policy. See the
46 MEMORY POLICY APIS section, below, for an overview of the system call
47 that a task may use to set/change it's task/process policy.
48
49 In a multi-threaded task, task policies apply only to the thread
50 [Linux kernel task] that installs the policy and any threads
51 subsequently created by that thread. Any sibling threads existing
52 at the time a new task policy is installed retain their current
53 policy.
54
55 A task policy applies only to pages allocated after the policy is
56 installed. Any pages already faulted in by the task when the task
57 changes its task policy remain where they were allocated based on
58 the policy at the time they were allocated.
59
60 VMA Policy: A "VMA" or "Virtual Memory Area" refers to a range of a task's
61 virtual adddress space. A task may define a specific policy for a range
62 of its virtual address space. See the MEMORY POLICIES APIS section,
63 below, for an overview of the mbind() system call used to set a VMA
64 policy.
65
66 A VMA policy will govern the allocation of pages that back this region of
67 the address space. Any regions of the task's address space that don't
68 have an explicit VMA policy will fall back to the task policy, which may
69 itself fall back to the System Default Policy.
70
71 VMA policies have a few complicating details:
72
73 VMA policy applies ONLY to anonymous pages. These include pages
74 allocated for anonymous segments, such as the task stack and heap, and
75 any regions of the address space mmap()ed with the MAP_ANONYMOUS flag.
76 If a VMA policy is applied to a file mapping, it will be ignored if
77 the mapping used the MAP_SHARED flag. If the file mapping used the
78 MAP_PRIVATE flag, the VMA policy will only be applied when an
79 anonymous page is allocated on an attempt to write to the mapping--
80 i.e., at Copy-On-Write.
81
82 VMA policies are shared between all tasks that share a virtual address
83 space--a.k.a. threads--independent of when the policy is installed; and
84 they are inherited across fork(). However, because VMA policies refer
85 to a specific region of a task's address space, and because the address
86 space is discarded and recreated on exec*(), VMA policies are NOT
87 inheritable across exec(). Thus, only NUMA-aware applications may
88 use VMA policies.
89
90 A task may install a new VMA policy on a sub-range of a previously
91 mmap()ed region. When this happens, Linux splits the existing virtual
92 memory area into 2 or 3 VMAs, each with it's own policy.
93
94 By default, VMA policy applies only to pages allocated after the policy
95 is installed. Any pages already faulted into the VMA range remain
96 where they were allocated based on the policy at the time they were
97 allocated. However, since 2.6.16, Linux supports page migration via
98 the mbind() system call, so that page contents can be moved to match
99 a newly installed policy.
100
101 Shared Policy: Conceptually, shared policies apply to "memory objects"
102 mapped shared into one or more tasks' distinct address spaces. An
103 application installs a shared policies the same way as VMA policies--using
104 the mbind() system call specifying a range of virtual addresses that map
105 the shared object. However, unlike VMA policies, which can be considered
106 to be an attribute of a range of a task's address space, shared policies
107 apply directly to the shared object. Thus, all tasks that attach to the
108 object share the policy, and all pages allocated for the shared object,
109 by any task, will obey the shared policy.
110
111 As of 2.6.22, only shared memory segments, created by shmget() or
112 mmap(MAP_ANONYMOUS|MAP_SHARED), support shared policy. When shared
113 policy support was added to Linux, the associated data structures were
114 added to hugetlbfs shmem segments. At the time, hugetlbfs did not
115 support allocation at fault time--a.k.a lazy allocation--so hugetlbfs
116 shmem segments were never "hooked up" to the shared policy support.
117 Although hugetlbfs segments now support lazy allocation, their support
118 for shared policy has not been completed.
119
120 As mentioned above [re: VMA policies], allocations of page cache
121 pages for regular files mmap()ed with MAP_SHARED ignore any VMA
122 policy installed on the virtual address range backed by the shared
123 file mapping. Rather, shared page cache pages, including pages backing
124 private mappings that have not yet been written by the task, follow
125 task policy, if any, else System Default Policy.
126
127 The shared policy infrastructure supports different policies on subset
128 ranges of the shared object. However, Linux still splits the VMA of
129 the task that installs the policy for each range of distinct policy.
130 Thus, different tasks that attach to a shared memory segment can have
131 different VMA configurations mapping that one shared object. This
132 can be seen by examining the /proc/<pid>/numa_maps of tasks sharing
133 a shared memory region, when one task has installed shared policy on
134 one or more ranges of the region.
135
136Components of Memory Policies
137
138 A Linux memory policy is a tuple consisting of a "mode" and an optional set
139 of nodes. The mode determine the behavior of the policy, while the
140 optional set of nodes can be viewed as the arguments to the behavior.
141
142 Internally, memory policies are implemented by a reference counted
143 structure, struct mempolicy. Details of this structure will be discussed
144 in context, below, as required to explain the behavior.
145
146 Note: in some functions AND in the struct mempolicy itself, the mode
147 is called "policy". However, to avoid confusion with the policy tuple,
148 this document will continue to use the term "mode".
149
150 Linux memory policy supports the following 4 behavioral modes:
151
152 Default Mode--MPOL_DEFAULT: The behavior specified by this mode is
153 context or scope dependent.
154
155 As mentioned in the Policy Scope section above, during normal
156 system operation, the System Default Policy is hard coded to
157 contain the Default mode.
158
159 In this context, default mode means "local" allocation--that is
160 attempt to allocate the page from the node associated with the cpu
161 where the fault occurs. If the "local" node has no memory, or the
162 node's memory can be exhausted [no free pages available], local
163 allocation will "fallback to"--attempt to allocate pages from--
164 "nearby" nodes, in order of increasing "distance".
165
166 Implementation detail -- subject to change: "Fallback" uses
167 a per node list of sibling nodes--called zonelists--built at
168 boot time, or when nodes or memory are added or removed from
169 the system [memory hotplug]. These per node zonelist are
170 constructed with nodes in order of increasing distance based
171 on information provided by the platform firmware.
172
173 When a task/process policy or a shared policy contains the Default
174 mode, this also means "local allocation", as described above.
175
176 In the context of a VMA, Default mode means "fall back to task
177 policy"--which may or may not specify Default mode. Thus, Default
178 mode can not be counted on to mean local allocation when used
179 on a non-shared region of the address space. However, see
180 MPOL_PREFERRED below.
181
182 The Default mode does not use the optional set of nodes.
183
184 MPOL_BIND: This mode specifies that memory must come from the
185 set of nodes specified by the policy.
186
187 The memory policy APIs do not specify an order in which the nodes
188 will be searched. However, unlike "local allocation", the Bind
189 policy does not consider the distance between the nodes. Rather,
190 allocations will fallback to the nodes specified by the policy in
191 order of numeric node id. Like everything in Linux, this is subject
192 to change.
193
194 MPOL_PREFERRED: This mode specifies that the allocation should be
195 attempted from the single node specified in the policy. If that
196 allocation fails, the kernel will search other nodes, exactly as
197 it would for a local allocation that started at the preferred node
198 in increasing distance from the preferred node. "Local" allocation
199 policy can be viewed as a Preferred policy that starts at the node
200 containing the cpu where the allocation takes place.
201
202 Internally, the Preferred policy uses a single node--the
203 preferred_node member of struct mempolicy. A "distinguished
204 value of this preferred_node, currently '-1', is interpreted
205 as "the node containing the cpu where the allocation takes
206 place"--local allocation. This is the way to specify
207 local allocation for a specific range of addresses--i.e. for
208 VMA policies.
209
210 MPOL_INTERLEAVED: This mode specifies that page allocations be
211 interleaved, on a page granularity, across the nodes specified in
212 the policy. This mode also behaves slightly differently, based on
213 the context where it is used:
214
215 For allocation of anonymous pages and shared memory pages,
216 Interleave mode indexes the set of nodes specified by the policy
217 using the page offset of the faulting address into the segment
218 [VMA] containing the address modulo the number of nodes specified
219 by the policy. It then attempts to allocate a page, starting at
220 the selected node, as if the node had been specified by a Preferred
221 policy or had been selected by a local allocation. That is,
222 allocation will follow the per node zonelist.
223
224 For allocation of page cache pages, Interleave mode indexes the set
225 of nodes specified by the policy using a node counter maintained
226 per task. This counter wraps around to the lowest specified node
227 after it reaches the highest specified node. This will tend to
228 spread the pages out over the nodes specified by the policy based
229 on the order in which they are allocated, rather than based on any
230 page offset into an address range or file. During system boot up,
231 the temporary interleaved system default policy works in this
232 mode.
233
234MEMORY POLICY APIs
235
236Linux supports 3 system calls for controlling memory policy. These APIS
237always affect only the calling task, the calling task's address space, or
238some shared object mapped into the calling task's address space.
239
240 Note: the headers that define these APIs and the parameter data types
241 for user space applications reside in a package that is not part of
242 the Linux kernel. The kernel system call interfaces, with the 'sys_'
243 prefix, are defined in <linux/syscalls.h>; the mode and flag
244 definitions are defined in <linux/mempolicy.h>.
245
246Set [Task] Memory Policy:
247
248 long set_mempolicy(int mode, const unsigned long *nmask,
249 unsigned long maxnode);
250
251 Set's the calling task's "task/process memory policy" to mode
252 specified by the 'mode' argument and the set of nodes defined
253 by 'nmask'. 'nmask' points to a bit mask of node ids containing
254 at least 'maxnode' ids.
255
256 See the set_mempolicy(2) man page for more details
257
258
259Get [Task] Memory Policy or Related Information
260
261 long get_mempolicy(int *mode,
262 const unsigned long *nmask, unsigned long maxnode,
263 void *addr, int flags);
264
265 Queries the "task/process memory policy" of the calling task, or
266 the policy or location of a specified virtual address, depending
267 on the 'flags' argument.
268
269 See the get_mempolicy(2) man page for more details
270
271
272Install VMA/Shared Policy for a Range of Task's Address Space
273
274 long mbind(void *start, unsigned long len, int mode,
275 const unsigned long *nmask, unsigned long maxnode,
276 unsigned flags);
277
278 mbind() installs the policy specified by (mode, nmask, maxnodes) as
279 a VMA policy for the range of the calling task's address space
280 specified by the 'start' and 'len' arguments. Additional actions
281 may be requested via the 'flags' argument.
282
283 See the mbind(2) man page for more details.
284
285MEMORY POLICY COMMAND LINE INTERFACE
286
287Although not strictly part of the Linux implementation of memory policy,
288a command line tool, numactl(8), exists that allows one to:
289
290+ set the task policy for a specified program via set_mempolicy(2), fork(2) and
291 exec(2)
292
293+ set the shared policy for a shared memory segment via mbind(2)
294
295The numactl(8) tool is packages with the run-time version of the library
296containing the memory policy system call wrappers. Some distributions
297package the headers and compile-time libraries in a separate development
298package.
299
300
301MEMORY POLICIES AND CPUSETS
302
303Memory policies work within cpusets as described above. For memory policies
304that require a node or set of nodes, the nodes are restricted to the set of
305nodes whose memories are allowed by the cpuset constraints. If the
306intersection of the set of nodes specified for the policy and the set of nodes
307allowed by the cpuset is the empty set, the policy is considered invalid and
308cannot be installed.
309
310The interaction of memory policies and cpusets can be problematic for a
311couple of reasons:
312
3131) the memory policy APIs take physical node id's as arguments. However, the
314 memory policy APIs do not provide a way to determine what nodes are valid
315 in the context where the application is running. An application MAY consult
316 the cpuset file system [directly or via an out of tree, and not generally
317 available, libcpuset API] to obtain this information, but then the
318 application must be aware that it is running in a cpuset and use what are
319 intended primarily as administrative APIs.
320
321 However, as long as the policy specifies at least one node that is valid
322 in the controlling cpuset, the policy can be used.
323
3242) when tasks in two cpusets share access to a memory region, such as shared
325 memory segments created by shmget() of mmap() with the MAP_ANONYMOUS and
326 MAP_SHARED flags, and any of the tasks install shared policy on the region,
327 only nodes whose memories are allowed in both cpusets may be used in the
328 policies. Again, obtaining this information requires "stepping outside"
329 the memory policy APIs, as well as knowing in what cpusets other task might
330 be attaching to the shared region, to use the cpuset information.
331 Furthermore, if the cpusets' allowed memory sets are disjoint, "local"
332 allocation is the only valid policy.
diff --git a/Documentation/watchdog/00-INDEX b/Documentation/watchdog/00-INDEX
new file mode 100644
index 000000000000..c3ea47e507fe
--- /dev/null
+++ b/Documentation/watchdog/00-INDEX
@@ -0,0 +1,10 @@
100-INDEX
2 - this file.
3pcwd-watchdog.txt
4 - documentation for Berkshire Products PC Watchdog ISA cards.
5src/
6 - directory holding watchdog related example programs.
7watchdog-api.txt
8 - description of the Linux Watchdog driver API.
9wdt.txt
10 - description of the Watchdog Timer Interfaces for Linux.
generated by cgit v1.2.2 (git 2.25.0) at 2024-12-17 22:01:45 -0500