diff options
author | Linus Torvalds <torvalds@woody.linux-foundation.org> | 2007-12-17 16:33:47 -0500 |
---|---|---|
committer | Linus Torvalds <torvalds@woody.linux-foundation.org> | 2007-12-17 16:33:47 -0500 |
commit | 87d5df6bde5764f1f6c18fe32f80e83f5010fa8c (patch) | |
tree | d3c861aba3777e032d70508a1133acc76031098c /Documentation | |
parent | 4942093e9d3b1ebdb27f43b8f3e483981e85107e (diff) | |
parent | ba3882a9178585289614c16a3b3f9b5f321d27b2 (diff) |
Merge git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-2.6
* git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-2.6:
HOWTO: update misspelling and word incorrected
add stable_api_nonsense.txt in korean
HOWTO: change addresses of maintainer and lxr url for Korean HOWTO
Add Documentation for FAIR_USER_SCHED sysfs files
HOWTO: Change man-page maintainer address for Japanese HOWTO
tipar: remove obsolete module
kobject: fix the documentation of how kobject_set_name works
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/ABI/testing/sysfs-kernel-uids | 14 | ||||
-rw-r--r-- | Documentation/ja_JP/HOWTO | 8 | ||||
-rw-r--r-- | Documentation/ko_KR/HOWTO | 144 | ||||
-rw-r--r-- | Documentation/ko_KR/stable_api_nonsense.txt | 195 | ||||
-rw-r--r-- | Documentation/tipar.txt | 93 |
5 files changed, 286 insertions, 168 deletions
diff --git a/Documentation/ABI/testing/sysfs-kernel-uids b/Documentation/ABI/testing/sysfs-kernel-uids new file mode 100644 index 000000000000..648d65dbc0e7 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-kernel-uids | |||
@@ -0,0 +1,14 @@ | |||
1 | What: /sys/kernel/uids/<uid>/cpu_shares | ||
2 | Date: December 2007 | ||
3 | Contact: Dhaval Giani <dhaval@linux.vnet.ibm.com> | ||
4 | Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> | ||
5 | Description: | ||
6 | The /sys/kernel/uids/<uid>/cpu_shares tunable is used | ||
7 | to set the cpu bandwidth a user is allowed. This is a | ||
8 | propotional value. What that means is that if there | ||
9 | are two users logged in, each with an equal number of | ||
10 | shares, then they will get equal CPU bandwidth. Another | ||
11 | example would be, if User A has shares = 1024 and user | ||
12 | B has shares = 2048, User B will get twice the CPU | ||
13 | bandwidth user A will. For more details refer | ||
14 | Documentation/sched-design-CFS.txt | ||
diff --git a/Documentation/ja_JP/HOWTO b/Documentation/ja_JP/HOWTO index d9d832c010ef..488c77fa3aae 100644 --- a/Documentation/ja_JP/HOWTO +++ b/Documentation/ja_JP/HOWTO | |||
@@ -11,14 +11,14 @@ for non English (read: Japanese) speakers and is not intended as a | |||
11 | fork. So if you have any comments or updates for this file, please try | 11 | fork. So if you have any comments or updates for this file, please try |
12 | to update the original English file first. | 12 | to update the original English file first. |
13 | 13 | ||
14 | Last Updated: 2007/09/23 | 14 | Last Updated: 2007/11/16 |
15 | ================================== | 15 | ================================== |
16 | これは、 | 16 | これは、 |
17 | linux-2.6.23/Documentation/HOWTO | 17 | linux-2.6.24/Documentation/HOWTO |
18 | の和訳です。 | 18 | の和訳です。 |
19 | 19 | ||
20 | 翻訳団体: JF プロジェクト < http://www.linux.or.jp/JF/ > | 20 | 翻訳団体: JF プロジェクト < http://www.linux.or.jp/JF/ > |
21 | 翻訳日: 2007/09/19 | 21 | 翻訳日: 2007/11/10 |
22 | 翻訳者: Tsugikazu Shibata <tshibata at ab dot jp dot nec dot com> | 22 | 翻訳者: Tsugikazu Shibata <tshibata at ab dot jp dot nec dot com> |
23 | 校正者: 松倉さん <nbh--mats at nifty dot com> | 23 | 校正者: 松倉さん <nbh--mats at nifty dot com> |
24 | 小林 雅典さん (Masanori Kobayasi) <zap03216 at nifty dot ne dot jp> | 24 | 小林 雅典さん (Masanori Kobayasi) <zap03216 at nifty dot ne dot jp> |
@@ -110,7 +110,7 @@ Linux カーネルソースツリーは幅広い範囲のドキュメントを� | |||
110 | 新しいドキュメントファイルも追加することを勧めます。 | 110 | 新しいドキュメントファイルも追加することを勧めます。 |
111 | カーネルの変更が、カーネルがユーザ空間に公開しているインターフェイスの | 111 | カーネルの変更が、カーネルがユーザ空間に公開しているインターフェイスの |
112 | 変更を引き起こす場合、その変更を説明するマニュアルページのパッチや情報 | 112 | 変更を引き起こす場合、その変更を説明するマニュアルページのパッチや情報 |
113 | をマニュアルページのメンテナ mtk-manpages@gmx.net に送ることを勧めま | 113 | をマニュアルページのメンテナ mtk.manpages@gmail.com に送ることを勧めま |
114 | す。 | 114 | す。 |
115 | 115 | ||
116 | 以下はカーネルソースツリーに含まれている読んでおくべきファイルの一覧で | 116 | 以下はカーネルソースツリーに含まれている読んでおくべきファイルの一覧で |
diff --git a/Documentation/ko_KR/HOWTO b/Documentation/ko_KR/HOWTO index b51d7ca842ba..029fca914c05 100644 --- a/Documentation/ko_KR/HOWTO +++ b/Documentation/ko_KR/HOWTO | |||
@@ -1,6 +1,6 @@ | |||
1 | NOTE: | 1 | NOTE: |
2 | This is a version of Documentation/HOWTO translated into korean | 2 | This is a version of Documentation/HOWTO translated into korean |
3 | This document is maintained by minchan Kim < minchan.kim@gmail.com> | 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 | 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. | 5 | a problem with the translation, please contact the maintainer of this file. |
6 | 6 | ||
@@ -14,7 +14,7 @@ try to update the original English file first. | |||
14 | Documentation/HOWTO | 14 | Documentation/HOWTO |
15 | 의 한글 번역입니다. | 15 | 의 한글 번역입니다. |
16 | 16 | ||
17 | 역자: 김민찬 <minchan.kim@gmail.com > | 17 | 역자: 김민찬 <minchan.kim@gmail.com> |
18 | 감수: 이제이미 <jamee.lee@samsung.com> | 18 | 감수: 이제이미 <jamee.lee@samsung.com> |
19 | ================================== | 19 | ================================== |
20 | 20 | ||
@@ -23,11 +23,11 @@ Documentation/HOWTO | |||
23 | 23 | ||
24 | 이 문서는 커널 개발에 있어 가장 중요한 문서이다. 이 문서는 | 24 | 이 문서는 커널 개발에 있어 가장 중요한 문서이다. 이 문서는 |
25 | 리눅스 커널 개발자가 되는 법과 리눅스 커널 개발 커뮤니티와 일하는 | 25 | 리눅스 커널 개발자가 되는 법과 리눅스 커널 개발 커뮤니티와 일하는 |
26 | 법을 담고있다. 커널 프로그래밍의기술적인 측면과 관련된 내용들은 | 26 | 법을 담고있다. 커널 프로그래밍의 기술적인 측면과 관련된 내용들은 |
27 | 포함하지 않으려고 하였지만 올바으로 여러분을 안내하는 데 도움이 | 27 | 포함하지 않으려고 하였지만 올바��� 길��� 여러분을 안내하는 데는 도움이 |
28 | 될 것이다. | 28 | 될 것이다. |
29 | 29 | ||
30 | 이 문서에서 오래된 것을 발견하면 문서의 아래쪽에 나열된 메인���너에게 | 30 | 이 문서에서 오래된 것을 발견하면 문서의 아래쪽에 나열된 메인���이너에게 |
31 | 패치를 보내달라. | 31 | 패치를 보내달라. |
32 | 32 | ||
33 | 33 | ||
@@ -36,12 +36,12 @@ Documentation/HOWTO | |||
36 | 36 | ||
37 | 자, 여러분은 리눅스 커널 개발자가 되는 법을 배우고 싶은가? 아니면 | 37 | 자, 여러분은 리눅스 커널 개발자가 되는 법을 배우고 싶은가? 아니면 |
38 | 상사로부터"이 장치를 위한 리눅스 드라이버를 작성하시오"라는 말을 | 38 | 상사로부터"이 장치를 위한 리눅스 드라이버를 작성하시오"라는 말을 |
39 | 들었는가? 이 문서��� 여러분이 겪게 될 과정과 커뮤니티와 일하는 법을 | 39 | 들었는가? 이 문서의 ���적은 여러분이 겪게 될 과정과 커뮤니티와 ���력���는 |
40 | 조언하여 여러분의 목적을 달성하기 위해 필요한 것 모두를 알려주는 | 40 | 법��� ���언하여 여러분의 목적을 달성하기 위해 필요한 것 모두를 알려주기 |
41 | 것이다. | 41 | ���함���다. |
42 | 42 | ||
43 | 커널은 대부분은 C로 작성되������고 몇몇 아키텍쳐의 의존적인 부분은 | 43 | 커널은 대부분은 C로 작성되어 있고 몇몇 아키텍쳐의 의존적인 부분은 |
44 | 어셈블리로 작성되���다. 커널 개발을 위해 C를 잘 이해하고 있어야 한다. | 44 | 어셈블리로 작성되��� ��다. 커널 개발을 위해 C를 잘 이해하고 있어야 한다. |
45 | 여러분이 특정 아키텍쳐의 low-level 개발을 할 것이 아니라면 | 45 | 여러분이 특정 아키텍쳐의 low-level 개발을 할 것이 아니라면 |
46 | 어셈블리(특정 아키텍쳐)는 잘 알아야 할 필요는 없다. | 46 | 어셈블리(특정 아키텍쳐)는 잘 알아야 할 필요는 없다. |
47 | 다음의 참고서적들은 기본에 충실한 C 교육이나 수년간의 경험에 견주지는 | 47 | 다음의 참고서적들은 기본에 충실한 C 교육이나 수년간의 경험에 견주지는 |
@@ -59,11 +59,11 @@ Documentation/HOWTO | |||
59 | 어떤 참고문서도 있지 않다. 정보를 얻기 위해서는 gcc info (`info gcc`)페이지를 | 59 | 어떤 참고문서도 있지 않다. 정보를 얻기 위해서는 gcc info (`info gcc`)페이지를 |
60 | 살펴보라. | 60 | 살펴보라. |
61 | 61 | ||
62 | 여러분은 기존의 개발 커뮤니티와 일하는 법을 배우려고 하고 있다는 것을 | 62 | 여러분은 기존의 개발 커뮤니티와 ���력���는 법을 배우려고 하고 있다는 것을 |
63 | 기억하라. 코딩, 스타일, ��������� 관한 훌륭한 표준을 가진 사람들이 모인 | 63 | 기억하라. 코딩, 스타일, 함��에 관한 훌륭한 표준을 가진 사람들이 모인 |
64 | 다양한 그룹이 있다. 이 표준들은 오랜동안 크고 지역적으로 분산된 팀들에 | 64 | 다양한 그룹이 있다. 이 표준들은 오랜동안 크고 지역적으로 분산된 팀들에 |
65 | 의해 가장 좋은 방법으로 일하기위하여 찾은 것을 기초로 만들어져왔다. | 65 | 의해 가장 좋은 방법으로 일하기 위하여 찾은 것을 기초로 만들어져 왔다. |
66 | 그 표준들은 문서화가 잘 되어 있기 때문에 가능한한 미리 많은 표준들에 | 66 | 그 표준들은 문서화가 잘 되어있기 때문에 가능한한 미리 많은 표준들에 |
67 | 관하여 배우려고 시도하라. 다른 사람들은 여러분이나 여러분의 회사가 | 67 | 관하여 배우려고 시도하라. 다른 사람들은 여러분이나 여러분의 회사가 |
68 | 일하는 방식에 적응하는 것을 원하지는 않는다. | 68 | 일하는 방식에 적응하는 것을 원하지는 않는다. |
69 | 69 | ||
@@ -73,7 +73,7 @@ Documentation/HOWTO | |||
73 | 73 | ||
74 | 리눅스 커널 소스 코드는 GPL로 배포(release)되었다. 소스트리의 메인 | 74 | 리눅스 커널 소스 코드는 GPL로 배포(release)되었다. 소스트리의 메인 |
75 | 디렉토리에 있는 라이센스에 관하여 상세하게 쓰여 있는 COPYING이라는 | 75 | 디렉토리에 있는 라이센스에 관하여 상세하게 쓰여 있는 COPYING이라는 |
76 | 파일을 봐라.여러분이 라이센스에 관한 더 깊은 문제를 가지고 있다면 | 76 | 파일을 봐라. 여러분이 라이센스에 관한 더 깊은 문제를 가지고 있다면 |
77 | 리눅스 커널 메일링 리스트에 묻지말고 변호사와 연락하라. 메일링 | 77 | 리눅스 커널 메일링 리스트에 묻지말고 변호사와 연락하라. 메일링 |
78 | 리스트들에 있는 사람들은 변호사가 아니기 때문에 법적 문제에 관하여 | 78 | 리스트들에 있는 사람들은 변호사가 아니기 때문에 법적 문제에 관하여 |
79 | 그들의 말에 의지해서는 안된다. | 79 | 그들의 말에 의지해서는 안된다. |
@@ -85,12 +85,12 @@ GPL에 관한 잦은 질문들과 답변들은 다음을 참조하라. | |||
85 | 문서 | 85 | 문서 |
86 | ---- | 86 | ---- |
87 | 87 | ||
88 | 리눅스 커널 소스 트리는 커널 커뮤니티와 일하는 법을 배우기 위�� ���은 | 88 | 리눅스 커널 소스 트리는 커널 커뮤니티와 ���력���는 법을 배우기위�� 훌���한 |
89 | 귀���한 문서들을 가지고 있다. 새로운 기능들이 커널에 들어가게 될 때, | 89 | ����한 문서들을 가지고 있다. 새로운 기능들이 커널에 들어가게 될 때, |
90 | 그 기능을 어떻게 사용하는지에 관한 설명을 위하여 새로운 문서 파일을 | 90 | 그 기능을 어떻게 사용하는지에 관한 설명을 위하여 새로운 문서 파일을 |
91 | 추가하는 것을 권장한다. 커널이 유저스페이스로 노출하는 인터페이스를 | 91 | 추가하는 것을 권장한다. 커널이 유저스페이스로 노출하는 인터페이스를 |
92 | 변경하게 되면 변경을 설명하는 메뉴얼 페이지들에 대한 패치나 정보를 | 92 | 변경하게 되면 변경을 설명하는 메뉴얼 페이지들에 대한 패치나 정보를 |
93 | mtk-manpages@gmx.net의 메인���너에게 보낼 것을 권장한다. | 93 | mtk.manpages@gmail.com의 메인���이너에게 보낼 것을 권장한다. |
94 | 94 | ||
95 | 다음은 커널 소스 트리에 있는 읽어야 할 파일들의 리스트이다. | 95 | 다음은 커널 소스 트리에 있는 읽어야 할 파일들의 리스트이다. |
96 | README | 96 | README |
@@ -105,7 +105,7 @@ mtk-manpages@gmx.net의 메인트너에게 보낼 것을 권장한다. | |||
105 | Documentation/CodingStyle | 105 | Documentation/CodingStyle |
106 | 이 문서는 리눅스 커널 코딩 스타일과 그렇게 한 몇몇 이유를 설명한다. | 106 | 이 문서는 리눅스 커널 코딩 스타일과 그렇게 한 몇몇 이유를 설명한다. |
107 | 모든 새로운 코드는 이 문서에 가이드라인들을 따라야 한다. 대부분의 | 107 | 모든 새로운 코드는 이 문서에 가이드라인들을 따라야 한다. 대부분의 |
108 | 메인���너들은 이 규칙을 따르는 패치들만을 받아들일 것이고 많은 사람들이 | 108 | 메인���이너들은 이 규칙을 따르는 패치들만을 받아들일 것이고 많은 사람들이 |
109 | 그 패치가 올바른 스타일일 경우만 코드를 검토할 것이다. | 109 | 그 패치가 올바른 스타일일 경우만 코드를 검토할 것이다. |
110 | 110 | ||
111 | Documentation/SubmittingPatches | 111 | Documentation/SubmittingPatches |
@@ -115,9 +115,10 @@ mtk-manpages@gmx.net의 메인트너에게 보낼 것을 권장한다. | |||
115 | - Email 내용들 | 115 | - Email 내용들 |
116 | - Email 양식 | 116 | - Email 양식 |
117 | - 그것을 누구에게 보낼지 | 117 | - 그것을 누구에게 보낼지 |
118 | 이러한 규칙들을 따르는 것이 성공을 보장하진 않는다(왜냐하면 모든 | 118 | 이러한 규칙들을 따르는 것이 성공(역자주: 패치가 받아들여 지는 것)을 |
119 | 패치들은 내용과 스타일에 관하여 면밀히 검토되기 때문이다). | 119 | 보장하진 않는다(왜냐하면 모든 패치들은 내용과 스타일에 관하여 |
120 | 그러나 규칙을 따르지 않는다면 거의 성공하지도 못할 것이다. | 120 | 면밀히 검토되기 때문이다). 그러나 규칙을 따르지 않는다면 거의 |
121 | 성공하지도 못할 것이다. | ||
121 | 122 | ||
122 | 올바른 패치들을 만드는 법에 관한 훌륭한 다른 문서들이 있다. | 123 | 올바른 패치들을 만드는 법에 관한 훌륭한 다른 문서들이 있다. |
123 | "The Perfect Patch" | 124 | "The Perfect Patch" |
@@ -126,13 +127,13 @@ mtk-manpages@gmx.net의 메인트너에게 보낼 것을 권장한다. | |||
126 | http://linux.yyz.us/patch-format.html | 127 | http://linux.yyz.us/patch-format.html |
127 | 128 | ||
128 | Documentation/stable_api_nonsense.txt | 129 | Documentation/stable_api_nonsense.txt |
129 | 이 문서는 의도적으로 커널이 변하지 않는 API를 갖지 않도록 결정한 | 130 | 이 문서는 의도적으로 커널이 ������하는 API를 갖지 않도록 결정한 |
130 | 이유를 설명하며 다음과 같은 것들을 포함한다. | 131 | 이유를 설명하며 다음과 같은 것들을 포함한다. |
131 | - 서브시스템 shim-layer(호환성을 위해?) | 132 | - 서브시스템 shim-layer(호환성을 위해?) |
132 | - 운영 체제들 간의 드라이버 이식성 | 133 | - 운영체제들간의 드라이버 이식성 |
133 | - 커널 소스 트리내에 빠른 변화를 늦추는 것(또는 빠른 변화를 막는 것) | 134 | - 커널 소스 트리내에 빠른 변화를 늦추는 것(또는 빠른 변화를 막는 것) |
134 | 이 문서는 리눅스 개발 철학을 이해하는데 필수적이며 다른 운영체제에서 | 135 | 이 문서는 리눅스 개발 철학을 이해하는데 필수적이며 다른 운영체제에서 |
135 | 리눅스로 ��겨오는 사람들에게는 매우 중요하다. | 136 | 리눅스로 ���향��는 사람들에게는 매우 중요하다. |
136 | 137 | ||
137 | 138 | ||
138 | Documentation/SecurityBugs | 139 | Documentation/SecurityBugs |
@@ -141,10 +142,10 @@ mtk-manpages@gmx.net의 메인트너에게 보낼 것을 권장한다. | |||
141 | 도와 달라. | 142 | 도와 달라. |
142 | 143 | ||
143 | Documentation/ManagementStyle | 144 | Documentation/ManagementStyle |
144 | 이 문서는 리눅스 커널 메인���너들이 어떻��� ���들의 방법론��� ���신�� | 145 | 이 문서는 리눅스 커널 메인���이너들이 그들의 방법론��� 녹아 있는 |
145 | 어떻게 공유하고 운영하는지를 설명한다. 이것은 커널 개발에 입문하는 | 146 | ���신을 ���떻게 공유하고 운영하는지를 설명한다. 이것은 커널 개발에 입문하는 |
146 | 모든 사람들(또는 커널 개발에 작은 호기심이라도 있는 사람들)이 | 147 | 모든 사람들(또는 커널 개발에 작은 호기심이라도 있는 사람들)이 |
147 | 읽어야 할 중요한 문서이다. 왜냐하면 이 문서는 커널 메인���너들의 | 148 | 읽어야 할 중요한 문서이다. 왜냐하면 이 문서는 커널 메인���이너들의 |
148 | 독특한 행동에 관하여 흔히 있는 오해들과 혼란들을 해소하고 있기 | 149 | 독특한 행동에 관하여 흔히 있는 오해들과 혼란들을 해소하고 있기 |
149 | 때문이다. | 150 | 때문이다. |
150 | 151 | ||
@@ -160,7 +161,7 @@ mtk-manpages@gmx.net의 메인트너에게 보낼 것을 권장한다. | |||
160 | 161 | ||
161 | Documentation/applying-patches.txt | 162 | Documentation/applying-patches.txt |
162 | 패치가 무엇이며 그것을 커널의 다른 개발 브랜치들에 어떻게 | 163 | 패치가 무엇이며 그것을 커널의 다른 개발 브랜치들에 어떻게 |
163 | 적용하는지에 관하여 자세히 설명 하고 있는 좋은 입문서이다. | 164 | 적용하는지에 관하여 자세히 설명하고 있는 좋은 입문서이다. |
164 | 165 | ||
165 | 커널은 소스 코드 그 자체에서 자동적으로 만들어질 수 있는 많은 문서들을 | 166 | 커널은 소스 코드 그 자체에서 자동적으로 만들어질 수 있는 많은 문서들을 |
166 | 가지고 있다. 이것은 커널 내의 API에 대한 모든 설명, 그리고 락킹을 | 167 | 가지고 있다. 이것은 커널 내의 API에 대한 모든 설명, 그리고 락킹을 |
@@ -192,7 +193,7 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H | |||
192 | 여러분이 어디서 시작해야 할진 모르지만 커널 개발 커뮤니티에 참여할 수 | 193 | 여러분이 어디서 시작해야 할진 모르지만 커널 개발 커뮤니티에 참여할 수 |
193 | 있는 일들을 찾길 원한다면 리눅스 커널 Janitor 프로젝트를 살펴봐라. | 194 | 있는 일들을 찾길 원한다면 리눅스 커널 Janitor 프로젝트를 살펴봐라. |
194 | http://janitor.kernelnewbies.org/ | 195 | http://janitor.kernelnewbies.org/ |
195 | 그곳은 시작하기에 아주 ��� ������ 곳이다. 그곳은 리눅스 커널 소스 트리내에 | 196 | 그곳은 시작하기에 훌���한 ������이다. 그곳은 리눅스 커널 소스 트리내에 |
196 | 간단히 정리되고 수정될 수 있는 문제들에 관하여 설명한다. 여러분은 이 | 197 | 간단히 정리되고 수정될 수 있는 문제들에 관하여 설명한다. 여러분은 이 |
197 | 프로젝트를 대표하는 개발자들과 일하면서 자신의 패치를 리눅스 커널 트리에 | 198 | 프로젝트를 대표하는 개발자들과 일하면서 자신의 패치를 리눅스 커널 트리에 |
198 | 반영하기 위한 기본적인 것들을 배우게 될것이며 여러분이 아직 아이디어를 | 199 | 반영하기 위한 기본적인 것들을 배우게 될것이며 여러분이 아직 아이디어를 |
@@ -212,7 +213,7 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H | |||
212 | 것은 Linux Cross-Reference project이며 그것은 자기 참조 방식이며 | 213 | 것은 Linux Cross-Reference project이며 그것은 자기 참조 방식이며 |
213 | 소스코드를 인덱스된 웹 페이지들의 형태로 보여준다. 최신의 멋진 커널 | 214 | 소스코드를 인덱스된 웹 페이지들의 형태로 보여준다. 최신의 멋진 커널 |
214 | 코드 저장소는 다음을 통하여 참조할 수 있다. | 215 | 코드 저장소는 다음을 통하여 참조할 수 있다. |
215 | http://sosdg.org/~coywolf/lxr/ | 216 | http://users.sosdg.org/~qiyong/lxr/ |
216 | 217 | ||
217 | 218 | ||
218 | 개발 프로세스 | 219 | 개발 프로세스 |
@@ -233,44 +234,45 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H | |||
233 | 2.6.x 커널들은 Linux Torvalds가 관리하며 kernel.org의 pub/linux/kernel/v2.6/ | 234 | 2.6.x 커널들은 Linux Torvalds가 관리하며 kernel.org의 pub/linux/kernel/v2.6/ |
234 | 디렉토리에서 참조될 수 있다.개발 프로세스는 다음과 같다. | 235 | 디렉토리에서 참조될 수 있다.개발 프로세스는 다음과 같다. |
235 | - 새로운 커널이 배포되자마자 2주의 시간이 주어진다. 이 기간동은 | 236 | - 새로운 커널이 배포되자마자 2주의 시간이 주어진다. 이 기간동은 |
236 | 메인���너들은 큰 diff들을 Linus에게 제출할 수 있다. 대개 이 패치들은 | 237 | 메인���이너들은 큰 diff들을 Linus에게 제출할 수 있다. 대개 이 패치들은 |
237 | 몇 주 동안 -mm 커널내에 이미 있었던 것들이다. 큰 변경들을 제출하는 데 | 238 | 몇 주 동안 -mm 커널내에 이미 있었던 것들이다. 큰 변경들을 제출하는 데 |
238 | 선호되는 방법은 git(커널의 소스 관리 툴, 더 많은 정보들은 http://git.or.cz/ | 239 | 선호되는 방법은 git(커널의 소스 관리 툴, 더 많은 정보들은 http://git.or.cz/ |
239 | 에서 참조할 수 있다)를 사용하는 것이지만 순수한 패치파일의 형식으로 보내��� | 240 | 에서 참조할 수 있다)를 사용하는 것이지만 순수한 패치파일의 형식으로 보내��� |
240 | 것도 무관하다. | 241 | 것도 무관하다. |
241 | - 2주 후에 -rc1 커널이 배포되며 지금부터는 전체 커널의 안정성에 영향을 | 242 | - 2주 후에 -rc1 커널이 배포되며 지금부터는 전체 커널의 안정성에 영향을 |
242 | 미칠수 있는 새로운 기능들을 포함하지 않는 패치들만�� 추가될 수 있다. | 243 | 미칠수 있는 새로운 기능들을 포함하지 않는 패치들만�� 추가될 수 있다. |
243 | 완전히 새로운 드라이버(혹은 파일시스템)는 -rc1 이후에만 받아들여진다는 | 244 | 완전히 새로운 드라이버(혹은 파일시스템)는 -rc1 이후에만 받아들여진다는 |
244 | 것을 기억해라. 왜냐하면 변경이 자체내에서만 발생하고 추가된 코드가 | 245 | 것을 기억해라. 왜냐하면 변경이 자체내에서만 발생하고 추가된 코드가 |
245 | 드라이버 외부의 다른 부분에는 영향을 주지 않으므로 그런 변경은 | 246 | 드라이버 외부의 다른 부분에는 영향을 주지 않으므로 그런 변경은 |
246 | 퇴보(regression)를 일으킬 만한 위험을 가지고 있지 않기 때문이다. -rc1이 | 247 | 회귀(역자주: 이전에는 존재하지 않았지만 새로운 기능추가나 변경으로 인해 |
248 | 생겨난 버그)를 일으킬 만한 위험을 가지고 있지 않기 때문이다. -rc1이 | ||
247 | 배포된 이후에 git를 사용하여 패치들을 Linus에게 보낼수 있지만 패치들은 | 249 | 배포된 이후에 git를 사용하여 패치들을 Linus에게 보낼수 있지만 패치들은 |
248 | 공식적인 메일링 리스트로 보내서 검토를 받을 필요가 있다. | 250 | 공식적인 메일링 리스트로 보내서 검토를 받을 필요가 있다. |
249 | - 새로운 -rc는 Linus는 현재 git tree가 테스트 하기에 충분히 안정된 상태에 | 251 | - 새로운 -rc는 Linus가 현재 git tree가 테스트 하기에 충분히 안정된 상태에 |
250 | 있다고 판단될 때마다 배포된다. 목표는 새로운 -rc 커널을 매주 배포하는 | 252 | 있다고 판단될 때마다 배포된다. 목표는 새로운 -rc 커널을 매주 배포하는 |
251 | 것이다. | 253 | 것이다. |
252 | - 이러한 프로세스는 커널이 "준비"되었다고 여겨질때까지 계속된다. | 254 | - 이러한 프로세스는 커널이 "준비(ready)"되었다고 여겨질때까지 계속된다. |
253 | 프로세스는 대체로 6주간 지속된다. | 255 | 프로세스는 대체로 6주간 지속된다. |
254 | - 각 -rc 배포에 있는 알려진 ���보의 목록들은 다음 URI에 남겨진다. | 256 | - 각 -rc 배포에 있는 알려진 ���귀의 목록들은 다음 URI에 남겨진다. |
255 | http://kernelnewbies.org/known_regressions | 257 | http://kernelnewbies.org/known_regressions |
256 | 258 | ||
257 | 커널 배포에 있어서 언급할만한 가치가 있는 리눅스 커널 메일링 리스트의 | 259 | 커널 배포에 있어서 언급할만한 가치가 있는 리눅스 커널 메일링 리스트의 |
258 | Andrew Morton의 글이 있다. | 260 | Andrew Morton의 글이 있다. |
259 | "커널이 언제 배포될지는 아무��� 모른다. 왜냐하면 배포는 알려진 | 261 | "커널이 언제 배포될지는 아무��� 모른다. 왜냐하면 배포는 알려진 |
260 | 버그의 상황에 따라 배포되는 것이지 미리정해 놓은 시간에 따라 | 262 | 버그의 상황에 따라 배포되는 것이지 미리정해 놓은 시간에 따라 |
261 | 배포되는 것은 아니기 때문이다." | 263 | 배포되는 것은 아니기 때문이다." |
262 | 264 | ||
263 | 2.6.x.y - 안정 커널 트리 | 265 | 2.6.x.y - 안정 커널 트리 |
264 | ------------------------ | 266 | ------------------------ |
265 | 267 | ||
266 | 4 자리 숫자로 이루어진 버젼의 커널들은 -stable 커널들이다. 그것들은 2.6.x | 268 | 4 자리 숫자로 이루어진 버젼의 커널들은 -stable 커널들이다. 그것들은 2.6.x |
267 | 커널에서 발견된 큰 ���������이나 보안 문제들 중 비교적 작고 중요한 수정들을 | 269 | 커널에서 발견된 큰 ���귀들이나 보안 문제들 중 비교적 작고 중요한 수정들을 |
268 | 포함한다. | 270 | 포함한다. |
269 | 271 | ||
270 | 이것은 가장 최근의 안정적인 커널을 원하는 사용자에게 추천되는 브랜치이며, | 272 | 이것은 가장 최근의 안정적인 커널을 원하는 사용자에게 추천되는 브랜치이며, |
271 | 개발/실험적 버젼을 테스트하는 것을 돕는���는 별로 관������ 없다. | 273 | 개발/실험적 버젼을 테스트하는 것을 돕고자 하는 사용자���과는 별로 관련이 없다. |
272 | 274 | ||
273 | 어떤 2.6.x.y 커널도 사용가능����� ���다면 그때는 가장 높은 숫자의 2.6.x | 275 | 어떤 2.6.x.y 커널도 사용�� ��� ���다면 그때는 가장 높은 숫자의 2.6.x |
274 | 커널이 현재의 안정 커널이다. | 276 | 커널이 현재의 안정 커널이다. |
275 | 277 | ||
276 | 2.6.x.y는 "stable" 팀<stable@kernel.org>에 의해 관리되며 거의 매번 격주로 | 278 | 2.6.x.y는 "stable" 팀<stable@kernel.org>에 의해 관리되며 거의 매번 격주로 |
@@ -294,7 +296,7 @@ Andrew Morton에 의해 배포된 실험적인 커널 패치들이다. Andrew는 | |||
294 | 서브시스템 커널 트리와 패치들을 가져와서 리눅스 커널 메일링 리스트로 | 296 | 서브시스템 커널 트리와 패치들을 가져와서 리눅스 커널 메일링 리스트로 |
295 | 온 많은 패치들과 한데 묶는다. 이 트리는 새로운 기능들과 패치들을 위한 | 297 | 온 많은 패치들과 한데 묶는다. 이 트리는 새로운 기능들과 패치들을 위한 |
296 | 장소를 제공하는 역할을 한다. 하나의 패치가 -mm에 한동안 있으면서 그 가치가 | 298 | 장소를 제공하는 역할을 한다. 하나의 패치가 -mm에 한동안 있으면서 그 가치가 |
297 | 증명되게 되면 Andrew나 서브시스템 메인���너는 그것을 메인라인에 포함시키기 | 299 | 증명되게 되면 Andrew나 서브시스템 메인���이너는 그것을 메인라인에 포함시키기 |
298 | 위하여 Linus에게 보낸다. | 300 | 위하여 Linus에게 보낸다. |
299 | 301 | ||
300 | 커널 트리에 포함하고 싶은 모든 새로운 패치들은 Linus에게 보내지기 전에 | 302 | 커널 트리에 포함하고 싶은 모든 새로운 패치들은 Linus에게 보내지기 전에 |
@@ -327,7 +329,7 @@ Andrew Morton에 의해 배포된 실험적인 커널 패치들이다. Andrew는 | |||
327 | - ACPI development tree, Len Brown <len.brown@intel.com > | 329 | - ACPI development tree, Len Brown <len.brown@intel.com > |
328 | git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git | 330 | git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git |
329 | 331 | ||
330 | - Block development tree, Jens Axboe <axboe@suse.de> | 332 | - Block development tree, Jens Axboe <jens.axboe@oracle.com> |
331 | git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git | 333 | git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git |
332 | 334 | ||
333 | - DRM development tree, Dave Airlie <airlied@linux.ie> | 335 | - DRM development tree, Dave Airlie <airlied@linux.ie> |
@@ -367,8 +369,8 @@ bugzilla.kernel.org는 리눅스 커널 개발자들이 커널의 버그를 추� | |||
367 | kernel bugzilla를 사용하는 자세한 방법은 다음을 참조하라. | 369 | kernel bugzilla를 사용하는 자세한 방법은 다음을 참조하라. |
368 | http://test.kernel.org/bugzilla/faq.html | 370 | http://test.kernel.org/bugzilla/faq.html |
369 | 371 | ||
370 | 메인 커널 소스 디렉토리에 있는 REPORTING-BUGS 파일은 커널 버그��� ��� 같�� | 372 | 메인 커널 소스 디렉토리에 있는 REPORTING-BUGS 파일은 커널 버그������ ���각되는 |
371 | 것을 보고하는는 법에 관한 좋은 템플릿이고 문제를 추적하기 위해서 커널 | 373 | 것을 보고하는 ������에 관한 좋은 템플릿이며 문제를 추적하기 위해서 커널 |
372 | 개발자들이 필요로 하는 정보가 무엇들인지를 상세히 설명하고 있다. | 374 | 개발자들이 필요로 하는 정보가 무엇들인지를 상세히 설명하고 있다. |
373 | 375 | ||
374 | 376 | ||
@@ -383,7 +385,7 @@ kernel bugzilla를 사용하는 자세한 방법은 다음을 참조하라. | |||
383 | 점수를 얻을 수 있는 가장 좋은 방법중의 하나이다. 왜냐하면 많은 사람들은 | 385 | 점수를 얻을 수 있는 가장 좋은 방법중의 하나이다. 왜냐하면 많은 사람들은 |
384 | 다른 사람들의 버그들을 수정하기 위하여 시간을 낭비하지 않기 때문이다. | 386 | 다른 사람들의 버그들을 수정하기 위하여 시간을 낭비하지 않기 때문이다. |
385 | 387 | ||
386 | 이미 보고된 버그 리포트들을 가지고 작업하기 위해서 http://bugzilla.kernelorg를 | 388 | 이미 보고된 버그 리포트들을 가지고 작업하기 위해서 http://bugzilla.kernel.org를 |
387 | 참조하라. 여러분이 앞으로 생겨날 버그 리포트들의 조언자가 되길 원한다면 | 389 | 참조하라. 여러분이 앞으로 생겨날 버그 리포트들의 조언자가 되길 원한다면 |
388 | bugme-new 메일링 리스트나(새로운 버그 리포트들만이 이곳에서 메일로 전해진다) | 390 | bugme-new 메일링 리스트나(새로운 버그 리포트들만이 이곳에서 메일로 전해진다) |
389 | bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메일로 전해진다) | 391 | bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메일로 전해진다) |
@@ -404,8 +406,8 @@ bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메� | |||
404 | 웹상의 많은 다른 곳에도 메일링 리스트의 아카이브들이 있다. | 406 | 웹상의 많은 다른 곳에도 메일링 리스트의 아카이브들이 있다. |
405 | 이러한 아카이브들을 찾으려면 검색 엔진을 사용하라. 예를 들어: | 407 | 이러한 아카이브들을 찾으려면 검색 엔진을 사용하라. 예를 들어: |
406 | http://dir.gmane.org/gmane.linux.kernel | 408 | http://dir.gmane.org/gmane.linux.kernel |
407 | 여러분이 새로운 문제에 관해 리스트에 올리기 전에 말하고 싶은 주제에 ��한 | 409 | 여러분이 새로운 문제에 관해 리스트에 올리기 전에 말하고 싶은 주제에 ��한 |
408 | 것을 아카이브에서 먼저 찾기를 강력히 권장한다. 이미 상세하게 토론된 많은 | 410 | 것을 아카이브에서 먼저 찾아보기를 강력히 권장한다. 이미 상세하게 토론된 많은 |
409 | 것들이 메일링 리스트의 아카이브에 기록되어 있다. | 411 | 것들이 메일링 리스트의 아카이브에 기록되어 있다. |
410 | 412 | ||
411 | 각각의 커널 서브시스템들의 대부분은 자신들의 개발에 관한 노력들로 이루어진 | 413 | 각각의 커널 서브시스템들의 대부분은 자신들의 개발에 관한 노력들로 이루어진 |
@@ -443,7 +445,7 @@ bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메� | |||
443 | 무엇보다도 메일링 리스트의 다른 구독자들에게 보여주려 한다는 것을 기억하라. | 445 | 무엇보다도 메일링 리스트의 다른 구독자들에게 보여주려 한다는 것을 기억하라. |
444 | 446 | ||
445 | 447 | ||
446 | 커뮤니티와 일하는 법 | 448 | 커뮤니티와 ���력���는 법 |
447 | -------------------- | 449 | -------------------- |
448 | 450 | ||
449 | 커널 커뮤니티의 목적은 가능한한 가장 좋은 커널을 제공하는 것이다. 여러분이 | 451 | 커널 커뮤니티의 목적은 가능한한 가장 좋은 커널을 제공하는 것이다. 여러분이 |
@@ -474,7 +476,7 @@ bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메� | |||
474 | 올바른 방향의 해결책으로 이끌어갈 의지가 있다면 받아들여질 것이라는 점을 | 476 | 올바른 방향의 해결책으로 이끌어갈 의지가 있다면 받아들여질 것이라는 점을 |
475 | 기억하라. | 477 | 기억하라. |
476 | 478 | ||
477 | 여러분의 첫 패치에 여러분이 수정해야하는 십여개 정도의 회신이 오는 | 479 | 여러분의 첫 패치에 여러분이 수정해야하는 십여개 정도의 회신이 오는 |
478 | 경우도 흔하다. 이것은 여러분의 패치가 받아들여지지 않을 것이라는 것을 | 480 | 경우도 흔하다. 이것은 여러분의 패치가 받아들여지지 않을 것이라는 것을 |
479 | 의미하는 것이 아니고 개인적으로 여러분에게 감정이 있어서 그러는 것도 | 481 | 의미하는 것이 아니고 개인적으로 여러분에게 감정이 있어서 그러는 것도 |
480 | 아니다. 간단히 여러분의 패치에 제기된 문제들을 수정하고 그것을 다시 | 482 | 아니다. 간단히 여러분의 패치에 제기된 문제들을 수정하고 그것을 다시 |
@@ -486,12 +488,12 @@ bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메� | |||
486 | 커널 커뮤니티는 가장 전통적인 회사의 개발 환경과는 다르다. 여기에 여러분들의 | 488 | 커널 커뮤니티는 가장 전통적인 회사의 개발 환경과는 다르다. 여기에 여러분들의 |
487 | 문제를 피하기 위한 목록이 있다. | 489 | 문제를 피하기 위한 목록이 있다. |
488 | 여러분들이 제안한 변경들에 관하여 말할 때 좋은 것들 : | 490 | 여러분들이 제안한 변경들에 관하여 말할 때 좋은 것들 : |
489 | - " 이것은 여러 문제들을 해겹합니다." | 491 | - "이것은 여러 문제들을 해겹합니다." |
490 | - "이것은 2000 라인의 코드를 제거합니다." | 492 | - "이것은 2000 라인의 코드를 제거합니다." |
491 | - "이것은 내가 말하려는 것에 관해 설명하는 패치입니다." | 493 | - "이것은 내가 말하려는 것에 관해 설명하는 패치입니다." |
492 | - "나는 5개의 다른 아키텍쳐에서 그것을 테스트했슴으로..." | 494 | - "나는 5개의 다른 아키텍쳐에서 그것을 테스트했슴으로..." |
493 | - "여기에 일련의 작은 패치들이 있��음로..." | 495 | - "여기에 일련의 작은 패치들이 있��음로..." |
494 | - "이것은 일반적인 머신에서 성능을 향상시��������..." | 496 | - "이것은 일반적인 머신에서 성능을 향상시��으로..." |
495 | 497 | ||
496 | 여러분들이 말할 때 피해야 할 좋지 않은 것들 : | 498 | 여러분들이 말할 때 피해야 할 좋지 않은 것들 : |
497 | - "우리를 그것을 AIT/ptx/Solaris에서 이러한 방법으로 했다. 그러므로 그것은 좋은 것임에 틀립없다..." | 499 | - "우리를 그것을 AIT/ptx/Solaris에서 이러한 방법으로 했다. 그러므로 그것은 좋은 것임에 틀립없다..." |
@@ -500,7 +502,7 @@ bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메� | |||
500 | - "이것은 우리의 엔터프라이즈 상품 라인을 위한 것이다." | 502 | - "이것은 우리의 엔터프라이즈 상품 라인을 위한 것이다." |
501 | - "여기에 나의 생각을 말하고 있는 1000 페이지 설계 문서가 있다." | 503 | - "여기에 나의 생각을 말하고 있는 1000 페이지 설계 문서가 있다." |
502 | - "나는 6달동안 이것을 했으니..." | 504 | - "나는 6달동안 이것을 했으니..." |
503 | - "여기��� 5000라인 짜리 패치가 있으니..." | 505 | - "여기��� 5000라인 짜리 패치가 있으니..." |
504 | - "나는 현재 뒤죽박죽인 것을 재작성했다. 그리고 여기에..." | 506 | - "나는 현재 뒤죽박죽인 것을 재작성했다. 그리고 여기에..." |
505 | - "나는 마감시한을 가지고 있으므로 이 패치는 지금 적용될 필요가 있다." | 507 | - "나는 마감시한을 가지고 있으므로 이 패치는 지금 적용될 필요가 있다." |
506 | 508 | ||
@@ -510,13 +512,13 @@ bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메� | |||
510 | 없다는 것이다. 리눅스 커널의 작업 환경에서는 단지 이메일 주소만 | 512 | 없다는 것이다. 리눅스 커널의 작업 환경에서는 단지 이메일 주소만 |
511 | 알수 있기 때문에 여성과 소수 민족들도 모두 받아들여진다. 국제적으로 | 513 | 알수 있기 때문에 여성과 소수 민족들도 모두 받아들여진다. 국제적으로 |
512 | 일하게 되는 측면은 사람의 이름에 근거하여 성별을 추측할 수 없게 | 514 | 일하게 되는 측면은 사람의 이름에 근거하여 성별을 추측할 수 없게 |
513 | 하기때문에 차별을 없애는 데 도움을 준다. Andrea라는 이름을 가진 남자와 | 515 | 하기때문에 차별을 없애는 데 도움을 준다. Andrea라는 이름을 가진 남자와 |
514 | Pat이라는 이름을 가진 여자가 있을 수도 있는 것이다. 리눅스 커널에서 | 516 | Pat이라는 이름을 가진 여자가 있을 수도 있는 것이다. 리눅스 커널에서 |
515 | 작업하며 생각을 표현해왔던 대부분의 여성들은 긍정적인 경험을 가지고 | 517 | 작업하며 생각을 표현해왔던 대부분의 여성들은 긍정적인 경험을 가지고 |
516 | 있다. | 518 | 있다. |
517 | 519 | ||
518 | 언어 장벽은 영어에 익숙하지 않은 몇몇 사람들에게 문제가 될 수도 있다. | 520 | 언어 장벽은 영어에 익숙하지 않은 몇몇 사람들에게 문제가 될 수도 있다. |
519 | 언어의 훌륭한 구사는 메일링 리스트에서 올바르게 자신의 생각을 | 521 | 언어의 훌륭한 구사는 메일링 리스트에서 올바르게 자신의 생각을 |
520 | 표현하기 위하여 필요하다. 그래서 여러분은 이메일을 보내기 전에 | 522 | 표현하기 위하여 필요하다. 그래서 여러분은 이메일을 보내기 전에 |
521 | 영어를 올바르게 사용하고 있는지를 체크하는 것이 바람직하다. | 523 | 영어를 올바르게 사용하고 있는지를 체크하는 것이 바람직하다. |
522 | 524 | ||
@@ -524,13 +526,13 @@ Pat이라는 이름을 가진 여자가 있을 수도 있는 것이다. 리눅� | |||
524 | 여러분의 변경을 나누어라 | 526 | 여러분의 변경을 나누어라 |
525 | ------------------------ | 527 | ------------------------ |
526 | 528 | ||
527 | 리눅스 커널 커뮤니티는 한꺼번에 굉장히 큰 코드의 묶음을 쉽게 | 529 | 리눅스 커널 커뮤니티는 한꺼번에 굉장히 큰 코드의 묶음(chunk)을 쉽게 |
528 | 받아들이지 않는다. 변경은 적절하게 소개되고, 검토되고, 각각의 | 530 | 받아들이지 않는다. 변경은 적절하게 소개되고, 검토되고, 각각의 |
529 | 부분으로 작게 나누어져야 한다. 이것은 회사에서 하는 것과는 정확히 | 531 | 부분으로 작게 나누어져야 한다. 이것은 회사에서 하는 것과는 정확히 |
530 | 반대되는 것이다. 여러분들의 제안은 개발 초기에 일찍이 소개되야 한다. | 532 | 반대되는 것이다. 여러분들의 제안은 개발 초기에 일찍이 소개되야 한다. |
531 | 그래서 여러분들은 자신이 하고 있는 것에 관하여 피드백을 받을 수 있게 | 533 | 그래서 여러분들은 자신이 하고 있는 것에 관하여 피드백을 받을 수 있게 |
532 | 된다. 커뮤니티가 여러분들이 커뮤니티와 함께 일하고 있다는 것을 | 534 | 된다. 커뮤니티가 여러분들이 커뮤니티와 함께 일하고 있다는 것을 |
533 | 느끼도록 만들고 커뮤니티가 여러분의 기능을 위한 쓰레기 장으로��� | 535 | 느끼도록 만들고 커뮤니티가 여러분의 기능을 위한 쓰레기 장으로��� |
534 | 사용되지 않고 있다는 것을 느끼게 하자. 그러나 메일링 리스트에 한번에 | 536 | 사용되지 않고 있다는 것을 느끼게 하자. 그러나 메일링 리스트에 한번에 |
535 | 50개의 이메일을 보내지는 말아라. 여러분들의 일련의 패치들은 항상 | 537 | 50개의 이메일을 보내지는 말아라. 여러분들의 일련의 패치들은 항상 |
536 | 더 작아야 한다. | 538 | 더 작아야 한다. |
@@ -539,7 +541,7 @@ Pat이라는 이름을 가진 여자가 있을 수도 있는 것이다. 리눅� | |||
539 | 541 | ||
540 | 1) 작은 패치들은 여러분의 패치들이 적용될 수 있는 확률을 높여준다. | 542 | 1) 작은 패치들은 여러분의 패치들이 적용될 수 있는 확률을 높여준다. |
541 | 왜냐하면 다른 사람들은 정확성을 검증하기 위하여 많은 시간과 노력을 | 543 | 왜냐하면 다른 사람들은 정확성을 검증하기 위하여 많은 시간과 노력을 |
542 | 들이기를 원하지 않는다. 5줄의 패치는 메인���너가 거의 몇 초간 힐끗 | 544 | 들이기를 원하지 않는다. 5줄의 패치는 메인���이너가 거의 몇 초간 힐끗 |
543 | 보면 적용될 수 있다. 그러나 500 줄의 패치는 정확성을 검토하기 위하여 | 545 | 보면 적용될 수 있다. 그러나 500 줄의 패치는 정확성을 검토하기 위하여 |
544 | 몇시간이 걸릴 수도 있다(걸리는 시간은 패치의 크기 혹은 다른 것에 | 546 | 몇시간이 걸릴 수도 있다(걸리는 시간은 패치의 크기 혹은 다른 것에 |
545 | 비례하여 기하급수적으로 늘어난다). | 547 | 비례하여 기하급수적으로 늘어난다). |
@@ -558,18 +560,18 @@ Pat이라는 이름을 가진 여자가 있을 수도 있는 것이다. 리눅� | |||
558 | 간결하고 가장 뛰어난 답을 보길 원한다. 훌륭한 학생은 이것을 알고 | 560 | 간결하고 가장 뛰어난 답을 보길 원한다. 훌륭한 학생은 이것을 알고 |
559 | 마지막으로 답을 얻기 전 중간 과정들을 제출하진 않는다. | 561 | 마지막으로 답을 얻기 전 중간 과정들을 제출하진 않는다. |
560 | 562 | ||
561 | 커널 개발도 마찬가지이다. 메인���너들과 검토하는 사람들은 문제를 | 563 | 커널 개발도 마찬가지이다. 메인���이너들과 검토하는 사람들은 문제를 |
562 | 풀어나가는 과정속에 숨겨진 과정을 보길 원하진 않는다. 그들은 | 564 | 풀어나가는 과정속에 숨겨진 과정을 보길 원하진 않는다. 그들은 |
563 | 간결하고 멋진 답을 보길 원한다." | 565 | 간결하고 멋진 답을 보길 원한다." |
564 | 566 | ||
565 | 커뮤니티와 ����� 일하며 뛰어난 답을 찾�� 여러분들의 완성���지 ���은 ���들 | 567 | 커뮤니티와 ��력하며 뛰어난 답을 찾는 ������ 여러분들의 ���마��지 못��� ���업들 |
566 | 사이에 균형을 유지해야 하는 어려������ 있�� 수 있다. 그러므로 프로세스의 | 568 | 사이에 균형을 유지해야 하는 것��� ���려�������� ���른���. 그러므로 프로세스의 |
567 | 초반에 여러분의 ���을 향상시키기위한 피드백을 얻는 것 뿐만 아니라 | 569 | 초반에 여러분의 ��������� 향상시키기위한 피드백을 얻는 것 뿐만 아니라 |
568 | 여러분들의 변경들을 작은 묶음으로 유지해서 심지어는 여러분의 작업의 | 570 | 여러분들의 변경들을 작은 묶음으로 유지해서 심지어는 여러분의 작업의 |
569 | 모든 부분이 지금은 포함될 준비가 되어있지 않지만 작은 부분은 이��� | 571 | 모든 부분이 지금은 포함될 준비가 되어있지 않지만 작은 부분은 ���써 |
570 | 받아들여질 수 있도록 유지하는 것이 바람직하다. | 572 | 받아들여질 수 있도록 유지하는 것이 바람직하다. |
571 | 573 | ||
572 | 또한 완성되지 않았고 "나중에 수정될 것이다." 와 같은 것들�� 포함하는 | 574 | 또한 완성되지 않았고 "나중에 수정될 것이다." 와 같은 것들�� 포함하는 |
573 | 패치들은 받아들여지지 않을 것이라는 점을 유념하라. | 575 | 패치들은 받아들여지지 않을 것이라는 점을 유념하라. |
574 | 576 | ||
575 | 변경을 정당화해라 | 577 | 변경을 정당화해라 |
@@ -577,7 +579,7 @@ Pat이라는 이름을 가진 여자가 있을 수도 있는 것이다. 리눅� | |||
577 | 579 | ||
578 | 여러분들의 나누어진 패치들을 리눅스 커뮤니티가 왜 반영해야 하는지를 | 580 | 여러분들의 나누어진 패치들을 리눅스 커뮤니티가 왜 반영해야 하는지를 |
579 | 알도록 하는 것은 매우 중요하다. 새로운 기능들이 필요하고 유용하다는 | 581 | 알도록 하는 것은 매우 중요하다. 새로운 기능들이 필요하고 유용하다는 |
580 | 것은 반드시 그에 ���는 이유가 있어야 한다. | 582 | 것은 반드시 그에 합���한 이유가 있어야 한다. |
581 | 583 | ||
582 | 584 | ||
583 | 변경을 문서화해라 | 585 | 변경을 문서화해라 |
@@ -588,7 +590,7 @@ Pat이라는 이름을 가진 여자가 있을 수도 있는 것이다. 리눅� | |||
588 | 것이다. 그리고 항상 그 내용을 보길 원하는 모든 사람들을 위해 보존될 | 590 | 것이다. 그리고 항상 그 내용을 보길 원하는 모든 사람들을 위해 보존될 |
589 | 것이다. 패치는 완벽하게 다음과 같은 내용들을 포함하여 설명해야 한다. | 591 | 것이다. 패치는 완벽하게 다음과 같은 내용들을 포함하여 설명해야 한다. |
590 | - 변경이 왜 필요한지 | 592 | - 변경이 왜 필요한지 |
591 | - 패치에 관한 전체 설계 ���프로치 | 593 | - 패치에 관한 전체 설계 ���근(approach) |
592 | - 구현 상세들 | 594 | - 구현 상세들 |
593 | - 테스트 결과들 | 595 | - 테스트 결과들 |
594 | 596 | ||
@@ -600,7 +602,7 @@ Pat이라는 이름을 가진 여자가 있을 수도 있는 것이다. 리눅� | |||
600 | 602 | ||
601 | 603 | ||
602 | 이 모든 것을 하는 것은 매우 어려운 일이다. 완벽히 소화하는 데는 적어도 몇년이 | 604 | 이 모든 것을 하는 것은 매우 어려운 일이다. 완벽히 소화하는 데는 적어도 몇년이 |
603 | 걸릴 수도 있다. 많은 인내와 결��가 필요한 계속되는 개선의 과정이다. 그러나 | 605 | 걸릴 수도 있다. 많은 인내와 결������ 필요한 계속되는 개선의 과정이다. 그러나 |
604 | 가능한한 포기하지 말라. 많은 사람들은 이전부터 해왔던 것이고 그 사람들도 | 606 | 가능한한 포기하지 말라. 많은 사람들은 이전부터 해왔던 것이고 그 사람들도 |
605 | 정확하게 여러분들이 지금 서 있는 그 곳부터 시작했었다. | 607 | 정확하게 여러분들이 지금 서 있는 그 곳부터 시작했었다. |
606 | 608 | ||
@@ -620,4 +622,4 @@ David A. Wheeler, Junio Hamano, Michael Kerrisk, and Alex Shepard에게도 감� | |||
620 | 622 | ||
621 | 623 | ||
622 | 624 | ||
623 | 메인���너: Greg Kroah-Hartman <greg@kroah.com> | 625 | 메인���이너: Greg Kroah-Hartman <greg@kroah.com> |
diff --git a/Documentation/ko_KR/stable_api_nonsense.txt b/Documentation/ko_KR/stable_api_nonsense.txt new file mode 100644 index 000000000000..8f2b0e1d98c4 --- /dev/null +++ b/Documentation/ko_KR/stable_api_nonsense.txt | |||
@@ -0,0 +1,195 @@ | |||
1 | NOTE: | ||
2 | This is a version of Documentation/stable_api_nonsense.txt translated | ||
3 | into korean | ||
4 | This document is maintained by barrios <minchan.kim@gmail.com> | ||
5 | If you find any difference between this document and the original file or | ||
6 | a problem with the translation, please contact the maintainer of this file. | ||
7 | |||
8 | Please also note that the purpose of this file is to be easier to | ||
9 | read for non English (read: korean) speakers and is not intended as | ||
10 | a fork. So if you have any comments or updates for this file please | ||
11 | try to update the original English file first. | ||
12 | |||
13 | ================================== | ||
14 | 이 문서는 | ||
15 | Documentation/stable_api_nonsense.txt | ||
16 | 의 한글 번역입니다. | ||
17 | |||
18 | 역자: 김민찬 <minchan.kim@gmail.com> | ||
19 | 감수: 이제이미 <jamee.lee@samsung.com> | ||
20 | ================================== | ||
21 | |||
22 | 리눅스 커널 드라이버 인터페이스 | ||
23 | (여러분들의 모든 질문에 대한 답 그리고 다른 몇가지) | ||
24 | |||
25 | Greg Kroah-Hartman <greg@kroah.com> | ||
26 | |||
27 | 이 문서는 리눅스가 왜 바이너리 커널 인터페이스를 갖지 않는지, 왜 변하지 | ||
28 | 않는(stable) 커널 인터페이스를 갖지 않는지를 설명하기 위해 쓰여졌다. | ||
29 | 이 문서는 커널과 유저공간 사이의 인터페이스가 아니라 커널 내부의 | ||
30 | 인터페이스들을 설명하고 있다는 것을 유념하라. 커널과 유저공간 사이의 | ||
31 | 인터페이스는 응용프로그램이 사용하는 syscall 인터페이스이다. 그 인터페이스는 | ||
32 | 오랫동안 거의 변하지 않았고 앞으로도 변하지 않을 것이다. 나는 pre 0.9에서 | ||
33 | 만들어졌지만 최신의 2.6 커널 배포에서도 잘 동작하는 프로그램을 가지고 | ||
34 | 있다. 이 인터페이스는 사용자와 응용프로그램 개발자들이 변하지 않을 것이라고 | ||
35 | 여길수 있는 것이다. | ||
36 | |||
37 | |||
38 | 초록 | ||
39 | ---- | ||
40 | 여러분은 변하지 않는 커널 인터페이스를 원한다고 생각하지만 실제로는 | ||
41 | 그렇지 않으며 심지어는 그것을 알아채지 못한다. 여러분이 원하는 것은 | ||
42 | 안정되게 실행되는 드라이버이며 드라이버가 메인 커널 트리에 있을 때 | ||
43 | 그런 안정적인 드라이버를 얻을 수 있게 된다. 또한 여러분의 드라이버가 | ||
44 | 메인 커널 트리에 있다면 다른 많은 좋은 이점들을 얻게 된다. 그러한 것들이 | ||
45 | 리눅스를 강건하고, 안정적이며, 성숙한 운영체제로 만들어 놓음으로써 | ||
46 | 여러분들로 하여금 바로 리눅스를 사용하게 만드는 이유이다. | ||
47 | |||
48 | |||
49 | 소개 | ||
50 | ---- | ||
51 | |||
52 | 커널 내부의 인터페이스가 바뀌는 것을 걱정하며 커널 드라이버를 작성하고 | ||
53 | 싶어하는 사람은 정말 이상한 사람이다. 세상의 대다수의 사람들은 이 인터페이스를 | ||
54 | 보지못할 것이며 전혀 걱정하지도 않는다. | ||
55 | |||
56 | 먼저, 나는 closed 소스, hidden 소스, binary blobs, 소스 wrappers, 또는 GPL로 | ||
57 | 배포되었지만 소스 코드를 갖고 있지 않은 커널 드라이버들을 설명하는 어떤 다른 | ||
58 | 용어들에 관한 어떤 법적인 문제에 관해서는 언급하지 않을 것이다. 어떤 법적인 | ||
59 | 질문들을 가지고 있다면 변호사와 연락하라. 나는 프로그래머이므로 여기서 기술적인 | ||
60 | 문제들만을 설명하려고 한다. (법적인 문제를 경시하는 것은 아니다. 그런 문제들은 | ||
61 | 엄연히 현실에 있고 여러분들은 항상 그 문제들을 인식하고 있을 필요는 있다.) | ||
62 | |||
63 | 자, 두가지의 주요 주제가 있다. 바이너리 커널 인터페이스들과 변하지 않는 | ||
64 | 커널 소스 인터페이들. 그것들은 서로 의존성을 가지고 있지만 바이너리 | ||
65 | 문제를 먼저 풀고 넘어갈 것이다. | ||
66 | |||
67 | |||
68 | |||
69 | 바이너리 커널 인터페이스 | ||
70 | ------------------------ | ||
71 | 우리가 변하지 않는 커널 소스 인터페이스를 가지고 있다고 가정하자. 그러면 | ||
72 | 바이너리 인터페이스 또한 자연적으로 변하지 않을까? 틀렸다. 리눅스 커널에 | ||
73 | 관한 다음 사실들을 생각해보라. | ||
74 | - 여러분들이 사용하는 C 컴파일러의 버젼에 따라 다른 커널 자료 구조들은 | ||
75 | 다른 alignmnet들을 갖게 될것이고 다른 방법으로(함수들을 inline으로 | ||
76 | 했느냐, 아니냐) 다른 함수들을 포함하는 것도 가능한다. 중요한 것은 | ||
77 | 개별적인 함수 구성이 아니라 자료 구조 패딩이 달라진다는 점이다. | ||
78 | - 여러분이 선택한 커널 빌드 옵션에 따라서 커널은 다양한 것들을 가정할 | ||
79 | 수 있다. | ||
80 | - 다른 구조체들은 다른 필드들을 포함할 수 있다. | ||
81 | - 몇몇 함수들은 전혀 구현되지 않을 수도 있다(즉, 몇몇 lock들은 | ||
82 | non-SMP 빌드에서는 사라져 버릴수도 있다). | ||
83 | - 커널내에 메모리는 build optoin들에 따라 다른 방법으로 align될수 | ||
84 | 있다. | ||
85 | - 리눅스는 많은 다양한 프로세서 아키텍쳐에서 실행된다. 한 아키텍쳐의 | ||
86 | 바이너리 드라이버를 다른 아키텍쳐에서 정상적으로 실행시킬 방법은 | ||
87 | 없다. | ||
88 | |||
89 | 커널을 빌드했던 C 컴파일러와 정확하게 같은 것을 사용하고 정확하게 같은 | ||
90 | 커널 구성(configuration)을 사용하여 여러분들의 모듈을 빌드하면 간단히 | ||
91 | 많은 문제들을 해결할 수 있다. 이렇게 하는 것은 여러분들이 하나의 리눅스 | ||
92 | 배포판의 하나의 배포 버젼을 위한 모듈만을 제공한다면 별일 아닐 것이다. | ||
93 | 그러나 각기 다른 리눅스 배포판마다 한번씩 빌드하는 수를 각 리눅스 배포판마다 | ||
94 | 제공하는 다른 릴리즈의 수와 곱하게 되면 이번에는 각 릴리즈들의 다른 빌드 | ||
95 | 옵션의 악몽과 마주하게 것이다. 또한 각 리눅스 배포판들은 다른 하드웨어 | ||
96 | 종류에(다른 프로세서 타입과 다른 옵션들) 맞춰져 있는 많은 다른 커널들을 | ||
97 | 배포한다. 그러므로 한번의 배포에서조차 여러분들의 모듈은 여러 버젼을 | ||
98 | 만들 필요가 있다. | ||
99 | |||
100 | 나를 믿어라. 여러분들은 이러한 종류의 배포를 지원하려고 시도한다면 시간이 | ||
101 | 지나면 미칠지경이 될 것이다. 난 이러한 것을 오래전에 아주 어렵게 배웠다... | ||
102 | |||
103 | |||
104 | |||
105 | 변하지않는 커널 소스 인터페이스들 | ||
106 | --------------------------------- | ||
107 | |||
108 | 리눅스 커널 드라이버를 계속해서 메인 커널 트리에 반영하지 않고 | ||
109 | 유지보수하려고 하는 사름들과 이 문제를 논의하게 되면 훨씬 더 | ||
110 | "논란의 여지가 많은" 주제가 될 것이다. | ||
111 | |||
112 | 리눅스 커널 개발은 끊임없이 빠른 속도로 이루어지고 있으며 결코 | ||
113 | 느슨해진 적이 없다. 커널 개발자들이 현재 인터페이스들에서 버그를 | ||
114 | 발견하거나 무엇인가 할수 있는 더 좋은 방법을 찾게 되었다고 하자. | ||
115 | 그들이 발견한 것을 실행한다면 아마도 더 잘 동작하도록 현재 인터페이스들을 | ||
116 | 수정하게 될 것이다. 그들이 그런 일을 하게되면 함수 이름들은 변하게 되고, | ||
117 | 구조체들은 늘어나거나 줄어들게 되고, 함수 파라미터들은 재작업될 것이다. | ||
118 | 이러한 일이 발생되면 커널 내에 이 인터페이스를 사용했던 인스턴스들이 동시에 | ||
119 | 수정될 것이며 이러한 과정은 모든 것이 계속해서 올바르게 동작할 것이라는 | ||
120 | 것을 보장한다. | ||
121 | |||
122 | 이러한 것의 한 예로써, 커널 내부의 USB 인터페이스들은 이 서브시스템이 | ||
123 | 생긴 이후로 적어도 3번의 다른 재작업을 겪었다. 이 재작업들은 많은 다른 | ||
124 | 문제들을 풀었다. | ||
125 | - 데이터 스트림들의 동기적인 모델에서 비동기적인 모델로의 변화. 이것은 | ||
126 | 많은 드라이버들의 복잡성을 줄이고 처리량을 향상시켜 현재는 거의 모든 | ||
127 | USB 장치들의 거의 최대 속도로 실행되고 있다. | ||
128 | - USB 드라이버가 USB 코어로부터 데이터 패킷들을 할당받로록 한 변경으로 | ||
129 | 인해서 지금의 모든 드라이버들은 많은 문서화된 데드락을 수정하기 위하여 | ||
130 | USB 코어에게 더 많은 정보를 제공해야만 한다. | ||
131 | |||
132 | 이것은 오랫동안 자신의 오래된 USB 인터페이스들을 유지해야 하는 closed 운영체제들과는 | ||
133 | 완전히 반대되는 것이다. closed된 운영체제들은 새로운 개발자들에게 우연히 낡은 | ||
134 | 인터페이스를 사용하게 할 기회를 주게되며, 적절하지 못한 방법으로 처리하게 되어 | ||
135 | 운영체제의 안정성을 해치는 문제를 야기하게 된다. | ||
136 | |||
137 | 이 두가지의 예들 모두, 모든 개발자들은 꼭 이루어져야 하는 중요한 변화들이라고 | ||
138 | 동의를 하였고 비교적 적은 고통으로 변경되어졌다. 리눅스가 변하지 않는 소스 | ||
139 | 인터페이스를 고집한다면, 새로운 인터페이스가 만들어지게 되며 반면 기존의 오래된 | ||
140 | 것들, 그리고 깨진 것들은 계속해서 유지되어야 하며 이러한 일들은 USB 개발자들에게 | ||
141 | 또 다른 일거리를 주게 된다. 모든 리눅스 USB 개발자들에게 자신의 그들의 업무를 | ||
142 | 마친 후 시간을 투자하여 아무 득도 없는 무료 봉사를 해달라고 하는 것은 가능성이 | ||
143 | 희박한 일이다. | ||
144 | |||
145 | 보안 문제 역시 리눅스에게는 매우 중요하다. 보안 문제가 발견되면 그것은 | ||
146 | 매우 짧은 시간 안에 수정된다. 보안 문제는 그 문제를 해결하기 위하여 | ||
147 | 여러번 내부 커널 인터페이스들을 재작업하게 만들었다. 이러한 문제가 | ||
148 | 발생하였을 때 그 인터페이스들을 사용하는 모든 드라이버들도 동시에 | ||
149 | 수정되어 보안 문제가 앞으로 갑작스럽게 생기지는 않을 것이라는 것을 | ||
150 | 보장한다. 내부 인터페이스들의 변경이 허락되지 않으면 이러한 종류의 보안 | ||
151 | 문제를 수정하고 그것이 다시 발생하지 않을 것이라고 보장하는 것은 가능하지 | ||
152 | 않을 것이다. | ||
153 | |||
154 | 커널 인터페이스들은 계속해서 정리되고 있다. 현재 인터페이스를 사용하는 | ||
155 | 사람이 한명도 없다면 그것은 삭제된다. 이것은 커널이 가능한한 가장 작게 | ||
156 | 유지되며 존재하는 모든 가능성이 있는 인터페이스들이 테스트된다는 것을 | ||
157 | 보장한다(사용되지 않는 인터페이스들은 유효성 검증을 하기가 거의 불가능하다). | ||
158 | |||
159 | |||
160 | 무엇을 해야 하나 | ||
161 | --------------- | ||
162 | 자, 여러분이 메인 커널 트리에 있지 않은 리눅스 커널 드라이버를 가지고 | ||
163 | 있다면 여러분은 즉, 개발자는 무엇을 해야 하나? 모든 배포판마다 다른 | ||
164 | 커널 버젼을 위한 바이너리 드라이버를 배포하는 것은 악몽이며 계속해서 | ||
165 | 변하고 있는 커널 인터페이스들의 맞처 유지보수하려고 시도하는 것은 힘든 | ||
166 | 일이다. | ||
167 | |||
168 | 간단하다. 여러분의 커널 드라이버를 메인 커널 트리에 반영하라(우리는 여기서 | ||
169 | GPL을 따르는 배포 드라이버에 관해 얘기하고 있다는 것을 상기하라. 여러분의 | ||
170 | 코드가 이러한 분류에 해당되지 않는다면 행운을 빈다. 여러분 스스로 어떻게든 | ||
171 | 해야만 한다). 여러분의 드라이버가 트리에 있게되면 커널 인터페이스가 | ||
172 | 변경되더라도 가장 먼저 커널에 변경을 가했던 사람에 의해서 수정될 것이다. | ||
173 | 이것은 여러분의 드라이버가 여러분의 별다른 노력없이 항상 빌드가 가능하며 | ||
174 | 동작하는 것을 보장한다. | ||
175 | |||
176 | 메인 커널 트리에 여러분의 드라이버를 반영하면 얻게 되는 장점들은 다음과 같다. | ||
177 | - 관리의 드는 비용(원래 개발자의)은 줄어줄면서 드라이버의 질은 향상될 것이다. | ||
178 | - 다른 개발자들이 여러분의 드라이버에 기능들을 추가 할 것이다. | ||
179 | - 다른 사람들은 여러분의 드라이버에 버그를 발견하고 수정할 것이다. | ||
180 | - 다른 사람들은 여러분의 드라이버의 개선점을 찾을 줄 것이다. | ||
181 | - 외부 인터페이스 변경으로 인해 여러분의 드라이버의 수정이 필요하다면 다른 | ||
182 | 사람들이 드라이버를 업데이트할 것이다. | ||
183 | - 여러분의 드라이버는 별다른 노력 없이 모든 리눅스 배포판에 자동적으로 | ||
184 | 추가될 것이다. | ||
185 | |||
186 | 리눅스는 다른 운영 체제보다 "쉽게 쓸수 있는(out of the box)" 많은 다른 장치들을 | ||
187 | 지원하고 어떤 다른 운영 체제보다 다양한 아키텍쳐위에서 이러한 장치들을 지원하기 때문에 | ||
188 | 이러한 증명된 개발 모델은 틀림없이 바로 가고 있는 것이다. | ||
189 | |||
190 | |||
191 | |||
192 | ------ | ||
193 | |||
194 | 이 문서의 초안을 검토해주고 코멘트 해준 Randy Dunlap, Andrew Morton, David Brownell, | ||
195 | Hanna Linder, Robert Love, 그리고 Nishanth Aravamudan에게 감사한다. | ||
diff --git a/Documentation/tipar.txt b/Documentation/tipar.txt deleted file mode 100644 index 67133baef6ef..000000000000 --- a/Documentation/tipar.txt +++ /dev/null | |||
@@ -1,93 +0,0 @@ | |||
1 | |||
2 | Parallel link cable for Texas Instruments handhelds | ||
3 | =================================================== | ||
4 | |||
5 | |||
6 | Author: Romain Lievin | ||
7 | Homepage: http://lpg.ticalc.org/prj_tidev/index.html | ||
8 | |||
9 | |||
10 | INTRODUCTION: | ||
11 | |||
12 | This is a driver for the very common home-made parallel link cable, a cable | ||
13 | designed for connecting TI8x/9x graphing calculators (handhelds) to a computer | ||
14 | or workstation (Alpha, Sparc). Given that driver is built on parport, the | ||
15 | parallel port abstraction layer, this driver is architecture-independent. | ||
16 | |||
17 | It can also be used with another device plugged on the same port (such as a | ||
18 | ZIP drive). I have a 100MB ZIP and both of them work fine! | ||
19 | |||
20 | If you need more information, please visit the 'TI drivers' homepage at the URL | ||
21 | above. | ||
22 | |||
23 | WHAT YOU NEED: | ||
24 | |||
25 | A TI calculator and a program capable of communicating with your calculator. | ||
26 | |||
27 | TiLP will work for sure (since I am its developer!). yal92 may be able to use | ||
28 | it by changing tidev for tipar (may require some hacking...). | ||
29 | |||
30 | HOW TO USE IT: | ||
31 | |||
32 | You must have first compiled parport support (CONFIG_PARPORT_DEV): either | ||
33 | compiled in your kernel, either as a module. | ||
34 | |||
35 | Next, (as root): | ||
36 | |||
37 | modprobe parport | ||
38 | modprobe tipar | ||
39 | |||
40 | If it is not already there (it usually is), create the device: | ||
41 | |||
42 | mknod /dev/tipar0 c 115 0 | ||
43 | mknod /dev/tipar1 c 115 1 | ||
44 | mknod /dev/tipar2 c 115 2 | ||
45 | |||
46 | You will have to set permissions on this device to allow you to read/write | ||
47 | from it: | ||
48 | |||
49 | chmod 666 /dev/tipar[0..2] | ||
50 | |||
51 | Now you are ready to run a linking program such as TiLP. Be sure to configure | ||
52 | it properly (RTFM). | ||
53 | |||
54 | MODULE PARAMETERS: | ||
55 | |||
56 | You can set these with: modprobe tipar NAME=VALUE | ||
57 | There is currently no way to set these on a per-cable basis. | ||
58 | |||
59 | NAME: timeout | ||
60 | TYPE: integer | ||
61 | DEFAULT: 15 | ||
62 | DESC: Timeout value in tenth of seconds. If no data is available once this | ||
63 | time has expired then the driver will return with a timeout error. | ||
64 | |||
65 | NAME: delay | ||
66 | TYPE: integer | ||
67 | DEFAULT: 10 | ||
68 | DESC: Inter-bit delay in micro-seconds. A lower value gives an higher data | ||
69 | rate but makes transmission less reliable. | ||
70 | |||
71 | These parameters can be changed at run time by any program via ioctl(2) calls | ||
72 | as listed in ./include/linux/ticable.h. | ||
73 | |||
74 | Rather than write 50 pages describing the ioctl() and so on, it is | ||
75 | perhaps more useful you look at ticables library (dev_link.c) that demonstrates | ||
76 | how to use them, and demonstrates the features of the driver. This is | ||
77 | probably a lot more useful to people interested in writing applications | ||
78 | that will be using this driver. | ||
79 | |||
80 | QUIRKS/BUGS: | ||
81 | |||
82 | None. | ||
83 | |||
84 | HOW TO CONTACT US: | ||
85 | |||
86 | You can email me at roms@lpg.ticalc.org. Please prefix the subject line | ||
87 | with "TIPAR: " so that I am certain to notice your message. | ||
88 | You can also mail JB at jb@jblache.org. He packaged these drivers for Debian. | ||
89 | |||
90 | CREDITS: | ||
91 | |||
92 | The code is based on tidev.c & parport.c. | ||
93 | The driver has been developed independently of Texas Instruments. | ||