Merge git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-2.6

What:		/sys/kernel/uids/<uid>/cpu_shares

Date:		December 2007

Contact:	Dhaval Giani <dhaval@linux.vnet.ibm.com>

		Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>

Description:

		The /sys/kernel/uids/<uid>/cpu_shares tunable is used

		to set the cpu bandwidth a user is allowed. This is a

		propotional value. What that means is that if there

		are two users logged in, each with an equal number of

		shares, then they will get equal CPU bandwidth. Another

		example would be, if User A has shares = 1024 and user

		B has shares = 2048, User B will get twice the CPU

		bandwidth user A will. For more details refer

		Documentation/sched-design-CFS.txt

fork. So if you have any comments or updates for this file, please try

to update the original English file first.

Last Updated: 2007/09/23

Last Updated: 2007/11/16

==================================

これは、

linux-2.6.23/Documentation/HOWTO

linux-2.6.24/Documentation/HOWTO

の和訳です。

翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ >

翻訳日： 2007/09/19

翻訳日： 2007/11/10

翻訳者： Tsugikazu Shibata <tshibata at ab dot jp dot nec dot com>

校正者： 松倉さん <nbh--mats at nifty dot com>

         小林 雅典さん (Masanori Kobayasi) <zap03216 at nifty dot ne dot jp>

新しいドキュメントファイルも追加することを勧めます。

カーネルの変更が、カーネルがユーザ空間に公開しているインターフェイスの

変更を引き起こす場合、その変更を説明するマニュアルページのパッチや情報

をマニュアルページのメンテナ mtk-manpages@gmx.net に送ることを勧めま

をマニュアルページのメンテナ mtk.manpages@gmail.com に送ることを勧めま

す。

以下はカーネルソースツリーに含まれている読んでおくべきファイルの一覧で

이 문서는 커널 개발에 있어 가장 중요한 문서이다. 이 문서는

리눅스 커널 개발자가 되는 법과 리눅스 커널 개발 커뮤니티와 일하는

법을 담고있다. 커널 프로그래밍의 기술적인 측면과 관련된 내용들은

포함하지 않으려고 하였지만 올바으로 여러분을 안내하는 데 도움이

포함하지 않으려고 하였지만 올바른 길로 여러분을 안내하는 데는 도움이

될 것이다.

이 문서에서 오래된 것을 발견하면 문서의 아래쪽에 나열된 메인트너에게

이 문서에서 오래된 것을 발견하면 문서의 아래쪽에 나열된 메인테이너에게

패치를 보내달라.

자, 여러분은 리눅스 커널 개발자가 되는 법을 배우고 싶은가? 아니면

상사로부터"이 장치를 위한 리눅스 드라이버를 작성하시오"라는 말을

들었는가? 이 문서는 여러분이 겪게 될 과정과 커뮤니티와 일하는 법을

조언하여 여러분의 목적을 달성하기 위해 필요한 것 모두를 알려주는

것이다.

들었는가? 이 문서의 목적은 여러분이 겪게 될 과정과 커뮤니티와 협력하는

법을 조언하여 여러분의 목적을 달성하기 위해 필요한 것 모두를 알려주기

위함이다.

커널은 대부분은 C로 작성되었어고 몇몇 아키텍쳐의 의존적인 부분은

어셈블리로 작성되었다. 커널 개발을 위해 C를 잘 이해하고 있어야 한다.

커널은 대부분은 C로 작성되어 있고 몇몇 아키텍쳐의 의존적인 부분은

어셈블리로 작성되어 있다. 커널 개발을 위해 C를 잘 이해하고 있어야 한다.

여러분이 특정 아키텍쳐의 low-level 개발을 할 것이 아니라면

어셈블리(특정 아키텍쳐)는 잘 알아야 할 필요는 없다.

다음의 참고서적들은 기본에 충실한 C 교육이나 수년간의 경험에 견주지는

어떤 참고문서도 있지 않다. 정보를 얻기 위해서는 gcc info (`info gcc`)페이지를

살펴보라.

여러분은 기존의 개발 커뮤니티와 일하는 법을 배우려고 하고 있다는 것을

기억하라. 코딩, 스타일, 절차에 관한 훌륭한 표준을 가진 사람들이 모인

여러분은 기존의 개발 커뮤니티와 협력하는 법을 배우려고 하고 있다는 것을

기억하라. 코딩, 스타일, 함수에 관한 훌륭한 표준을 가진 사람들이 모인

다양한 그룹이 있다. 이 표준들은 오랜동안 크고 지역적으로 분산된 팀들에

의해 가장 좋은 방법으로 일하기 위하여 찾은 것을 기초로 만들어져 왔다.

그 표준들은 문서화가 잘 되어있기 때문에 가능한한 미리 많은 표준들에

문서

----

리눅스 커널 소스 트리는 커널 커뮤니티와 일하는 법을 배우기 위한 많은

귀중한 문서들을 가지고 있다. 새로운 기능들이 커널에 들어가게 될 때,

리눅스 커널 소스 트리는 커널 커뮤니티와 협력하는 법을 배우기위해 훌륭한

다양한 문서들을 가지고 있다. 새로운 기능들이 커널에 들어가게 될 때,

그 기능을 어떻게 사용하는지에 관한 설명을 위하여 새로운 문서 파일을

추가하는 것을 권장한다. 커널이 유저스페이스로 노출하는 인터페이스를

변경하게 되면 변경을 설명하는 메뉴얼 페이지들에 대한 패치나 정보를

mtk-manpages@gmx.net의 메인트너에게 보낼 것을 권장한다.

mtk.manpages@gmail.com의 메인테이너에게 보낼 것을 권장한다.

다음은 커널 소스 트리에 있는 읽어야 할 파일들의 리스트이다.

  README

  Documentation/CodingStyle

    이 문서는 리눅스 커널 코딩 스타일과 그렇게 한 몇몇 이유를 설명한다.

    모든 새로운 코드는 이 문서에 가이드라인들을 따라야 한다. 대부분의

    메인트너들은 이 규칙을 따르는 패치들만을 받아들일 것이고 많은 사람들이

    메인테이너들은 이 규칙을 따르는 패치들만을 받아들일 것이고 많은 사람들이

    그 패치가 올바른 스타일일 경우만 코드를 검토할 것이다.

  Documentation/SubmittingPatches

       - Email 내용들

       - Email 양식

       - 그것을 누구에게 보낼지

    이러한 규칙들을 따르는 것이 성공을 보장하진 않는다(왜냐하면 모든

    패치들은 내용과 스타일에 관하여 면밀히 검토되기 때문이다).

    그러나 규칙을 따르지 않는다면 거의 성공하지도 못할 것이다.

    이러한 규칙들을 따르는 것이 성공(역자주: 패치가 받아들여 지는 것)을

    보장하진 않는다(왜냐하면 모든 패치들은 내용과 스타일에 관하여

    면밀히 검토되기 때문이다). 그러나 규칙을 따르지 않는다면 거의

    성공하지도 못할 것이다.

    올바른 패치들을 만드는 법에 관한 훌륭한 다른 문서들이 있다.

    "The Perfect Patch"

        http://linux.yyz.us/patch-format.html

   Documentation/stable_api_nonsense.txt

    이 문서는 의도적으로 커널이 변하지 않는 API를 갖지 않도록 결정한

    이 문서는 의도적으로 커널이 불변하는 API를 갖지 않도록 결정한

    이유를 설명하며 다음과 같은 것들을 포함한다.

       - 서브시스템 shim-layer(호환성을 위해?)

       - 운영체제들간의 드라이버 이식성

       - 커널 소스 트리내에 빠른 변화를 늦추는 것(또는 빠른 변화를 막는 것)

    이 문서는 리눅스 개발 철학을 이해하는데 필수적이며 다른 운영체제에서

    리눅스로 옮겨오는 사람들에게는 매우 중요하다.

    리눅스로 전향하는 사람들에게는 매우 중요하다.

  Documentation/SecurityBugs

    도와 달라.

  Documentation/ManagementStyle

    이 문서는 리눅스 커널 메인트너들이 어떻게 그들의 방법론의 정신을

    어떻게 공유하고 운영하는지를 설명한다. 이것은 커널 개발에 입문하는

    이 문서는 리눅스 커널 메인테이너들이 그들의 방법론에 녹아 있는

    정신을 어떻게 공유하고 운영하는지를 설명한다. 이것은 커널 개발에 입문하는

    모든 사람들(또는 커널 개발에 작은 호기심이라도 있는 사람들)이

    읽어야 할 중요한 문서이다. 왜냐하면 이 문서는 커널 메인트너들의

    읽어야 할 중요한 문서이다. 왜냐하면 이 문서는 커널 메인테이너들의

    독특한 행동에 관하여 흔히 있는 오해들과 혼란들을 해소하고 있기

    때문이다.

여러분이 어디서 시작해야 할진 모르지만 커널 개발 커뮤니티에 참여할 수

있는 일들을 찾길 원한다면 리눅스 커널 Janitor 프로젝트를 살펴봐라.

         http://janitor.kernelnewbies.org/

그곳은 시작하기에 아주 딱 좋은 곳이다. 그곳은 리눅스 커널 소스 트리내에

그곳은 시작하기에 훌륭한 장소이다. 그곳은 리눅스 커널 소스 트리내에

간단히 정리되고 수정될 수 있는 문제들에 관하여 설명한다. 여러분은 이

프로젝트를 대표하는 개발자들과 일하면서 자신의 패치를 리눅스 커널 트리에

반영하기 위한 기본적인 것들을 배우게 될것이며 여러분이 아직 아이디어를

것은 Linux Cross-Reference project이며 그것은 자기 참조 방식이며

소스코드를 인덱스된 웹 페이지들의 형태로 보여준다. 최신의 멋진 커널

코드 저장소는 다음을 통하여 참조할 수 있다.

      http://sosdg.org/~coywolf/lxr/

      http://users.sosdg.org/~qiyong/lxr/

개발 프로세스

2.6.x 커널들은 Linux Torvalds가 관리하며 kernel.org의 pub/linux/kernel/v2.6/

디렉토리에서 참조될 수 있다.개발 프로세스는 다음과 같다.

  - 새로운 커널이 배포되자마자 2주의 시간이 주어진다. 이 기간동은

    메인트너들은 큰 diff들을 Linus에게 제출할 수 있다. 대개 이 패치들은

    메인테이너들은 큰 diff들을 Linus에게 제출할 수 있다. 대개 이 패치들은

    몇 주 동안 -mm 커널내에 이미 있었던 것들이다. 큰 변경들을 제출하는 데

    선호되는 방법은  git(커널의 소스 관리 툴, 더 많은 정보들은 http://git.or.cz/

    에서 참조할 수 있다)를 사용하는 것이지만 순수한 패치파일의 형식으로 보내도

    에서 참조할 수 있다)를 사용하는 것이지만 순수한 패치파일의 형식으로 보내는

    것도 무관하다.

  - 2주 후에 -rc1 커널이 배포되며 지금부터는 전체 커널의 안정성에 영향을

    미칠수 있는 새로운 기능들을 포함하지 않는 패치들만을 추가될 수 있다.

    미칠수 있는 새로운 기능들을 포함하지 않는 패치들만이 추가될 수 있다.

    완전히 새로운 드라이버(혹은 파일시스템)는 -rc1 이후에만 받아들여진다는

    것을 기억해라. 왜냐하면 변경이 자체내에서만 발생하고 추가된 코드가

    드라이버 외부의 다른 부분에는 영향을 주지 않으므로 그런 변경은

    퇴보(regression)를 일으킬 만한 위험을 가지고 있지 않기 때문이다. -rc1이

    회귀(역자주: 이전에는 존재하지 않았지만 새로운 기능추가나 변경으로 인해

		생겨난 버그)를 일으킬 만한 위험을 가지고 있지 않기 때문이다. -rc1이

    배포된 이후에 git를 사용하여 패치들을 Linus에게 보낼수 있지만 패치들은

    공식적인 메일링 리스트로 보내서 검토를 받을 필요가 있다.

  - 새로운 -rc는 Linus는 현재 git tree가 테스트 하기에 충분히 안정된 상태에

  - 새로운 -rc는 Linus가 현재 git tree가 테스트 하기에 충분히 안정된 상태에

    있다고 판단될 때마다 배포된다. 목표는 새로운 -rc 커널을 매주 배포하는

    것이다.

  - 이러한 프로세스는 커널이 "준비"되었다고 여겨질때까지 계속된다.

  - 이러한 프로세스는 커널이 "준비(ready)"되었다고 여겨질때까지 계속된다.

    프로세스는 대체로 6주간 지속된다.

    - 각 -rc 배포에 있는 알려진 퇴보의 목록들은 다음 URI에 남겨진다.

  - 각 -rc 배포에 있는 알려진 회귀의 목록들은 다음 URI에 남겨진다.

    http://kernelnewbies.org/known_regressions

커널 배포에 있어서 언급할만한 가치가 있는 리눅스 커널 메일링 리스트의

Andrew Morton의 글이 있다.

        "커널이 언제 배포될지는 아무로 모른다. 왜냐하면 배포는 알려진

        "커널이 언제 배포될지는 아무도 모른다. 왜냐하면 배포는 알려진

         버그의 상황에 따라 배포되는 것이지 미리정해 놓은 시간에 따라

         배포되는 것은 아니기 때문이다."

------------------------

4 자리 숫자로 이루어진 버젼의 커널들은 -stable 커널들이다. 그것들은 2.6.x

커널에서 발견된 큰 퇴보들이나 보안 문제들 중 비교적 작고 중요한 수정들을

커널에서 발견된 큰 회귀들이나 보안 문제들 중 비교적 작고 중요한 수정들을

포함한다.

이것은 가장 최근의 안정적인 커널을 원하는 사용자에게 추천되는 브랜치이며,

개발/실험적 버젼을 테스트하는 것을 돕는데는 별로 관심이 없다.

개발/실험적 버젼을 테스트하는 것을 돕고자 하는 사용자들과는 별로 관련이 없다.

어떤 2.6.x.y 커널도 사용가능하지 않다면 그때는 가장 높은 숫자의 2.6.x

어떤 2.6.x.y 커널도 사용할 수 없다면 그때는 가장 높은 숫자의 2.6.x

커널이 현재의 안정 커널이다.

2.6.x.y는 "stable" 팀<stable@kernel.org>에 의해 관리되며 거의 매번 격주로

서브시스템 커널 트리와 패치들을 가져와서 리눅스 커널 메일링 리스트로

온 많은 패치들과 한데 묶는다. 이 트리는 새로운 기능들과 패치들을 위한

장소를 제공하는 역할을 한다. 하나의 패치가 -mm에 한동안 있으면서 그 가치가

증명되게 되면 Andrew나 서브시스템 메인트너는 그것을 메인라인에 포함시키기

증명되게 되면 Andrew나 서브시스템 메인테이너는 그것을 메인라인에 포함시키기

위하여 Linus에게 보낸다.

커널 트리에 포함하고 싶은 모든 새로운 패치들은 Linus에게 보내지기 전에

    - ACPI development tree, Len Brown <len.brown@intel.com >

    git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git

    - Block development tree, Jens Axboe <axboe@suse.de>

    - Block development tree, Jens Axboe <jens.axboe@oracle.com>

    git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git

    - DRM development tree, Dave Airlie <airlied@linux.ie>

kernel bugzilla를 사용하는 자세한 방법은 다음을 참조하라.

    http://test.kernel.org/bugzilla/faq.html

메인 커널 소스 디렉토리에 있는 REPORTING-BUGS 파일은 커널 버그일 것 같은

것을 보고하는는 법에 관한 좋은 템플릿이고 문제를 추적하기 위해서 커널

메인 커널 소스 디렉토리에 있는 REPORTING-BUGS 파일은 커널 버그라고 생각되는

것을 보고하는 방법에 관한 좋은 템플릿이며 문제를 추적하기 위해서 커널

개발자들이 필요로 하는 정보가 무엇들인지를 상세히 설명하고 있다.

점수를 얻을 수 있는 가장 좋은 방법중의 하나이다. 왜냐하면 많은 사람들은

다른 사람들의 버그들을 수정하기 위하여 시간을 낭비하지 않기 때문이다.

이미 보고된 버그 리포트들을 가지고 작업하기 위해서 http://bugzilla.kernelorg를

이미 보고된 버그 리포트들을 가지고 작업하기 위해서 http://bugzilla.kernel.org를

참조하라. 여러분이 앞으로 생겨날 버그 리포트들의 조언자가 되길 원한다면

bugme-new 메일링 리스트나(새로운 버그 리포트들만이 이곳에서 메일로 전해진다)

bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메일로 전해진다)

웹상의 많은 다른 곳에도 메일링 리스트의 아카이브들이 있다.

이러한 아카이브들을 찾으려면 검색 엔진을 사용하라. 예를 들어:

      http://dir.gmane.org/gmane.linux.kernel

여러분이 새로운 문제에 관해 리스트에 올리기 전에 말하고 싶은 주제에 대한

것을 아카이브에서 먼저 찾기를 강력히 권장한다. 이미 상세하게 토론된 많은

여러분이 새로운 문제에 관해 리스트에 올리기 전에 말하고 싶은 주제에 관한

것을 아카이브에서 먼저 찾아보기를 강력히 권장한다. 이미 상세하게 토론된 많은

것들이 메일링 리스트의 아카이브에 기록되어 있다.

각각의 커널 서브시스템들의 대부분은 자신들의 개발에 관한 노력들로 이루어진

무엇보다도 메일링 리스트의 다른 구독자들에게 보여주려 한다는 것을 기억하라.

커뮤니티와 일하는 법

커뮤니티와 협력하는 법

--------------------

커널 커뮤니티의 목적은 가능한한 가장 좋은 커널을 제공하는 것이다. 여러분이

    - "이것은 2000 라인의 코드를 제거합니다."

    - "이것은 내가 말하려는 것에 관해 설명하는 패치입니다."

    - "나는 5개의 다른 아키텍쳐에서 그것을 테스트했슴으로..."

    - "여기에 일련의 작은 패치들이 있습음로..."

    - "이것은 일반적인 머신에서 성능을 향상시키므로..."

    - "여기에 일련의 작은 패치들이 있슴음로..."

    - "이것은 일반적인 머신에서 성능을 향상시킴으로..."

  여러분들이 말할 때 피해야 할 좋지 않은 것들 :

    - "우리를 그것을 AIT/ptx/Solaris에서 이러한 방법으로 했다. 그러므로 그것은 좋은 것임에 틀립없다..."

    - "이것은 우리의 엔터프라이즈 상품 라인을 위한 것이다."

    - "여기에 나의 생각을 말하고 있는 1000 페이지 설계 문서가 있다."

    - "나는 6달동안 이것을 했으니..."

    - "여기세 5000라인 짜리 패치가 있으니..."

    - "여기에 5000라인 짜리 패치가 있으니..."

    - "나는 현재 뒤죽박죽인 것을 재작성했다. 그리고 여기에..."

    - "나는 마감시한을 가지고 있으므로 이 패치는 지금 적용될 필요가 있다."

여러분의 변경을 나누어라

------------------------

리눅스 커널 커뮤니티는 한꺼번에 굉장히 큰 코드의 묶음을 쉽게

리눅스 커널 커뮤니티는 한꺼번에 굉장히 큰 코드의 묶음(chunk)을 쉽게

받아들이지 않는다. 변경은 적절하게 소개되고, 검토되고, 각각의

부분으로 작게 나누어져야 한다. 이것은 회사에서 하는 것과는 정확히

반대되는 것이다. 여러분들의 제안은 개발 초기에 일찍이 소개되야 한다.

그래서 여러분들은 자신이 하고 있는 것에 관하여 피드백을 받을 수 있게

된다. 커뮤니티가 여러분들이 커뮤니티와 함께 일하고 있다는 것을

느끼도록 만들고 커뮤니티가 여러분의 기능을 위한 쓰레기 장으로서

느끼도록 만들고 커뮤니티가 여러분의 기능을 위한 쓰레기 장으로써

사용되지 않고 있다는 것을 느끼게 하자. 그러나 메일링 리스트에 한번에

50개의 이메일을 보내지는 말아라. 여러분들의 일련의 패치들은 항상

더 작아야 한다.

1) 작은 패치들은 여러분의 패치들이 적용될 수 있는 확률을 높여준다.

   왜냐하면 다른 사람들은 정확성을 검증하기 위하여 많은 시간과 노력을

   들이기를 원하지 않는다. 5줄의 패치는 메인트너가 거의 몇 초간 힐끗

   들이기를 원하지 않는다. 5줄의 패치는 메인테이너가 거의 몇 초간 힐끗

   보면 적용될 수 있다. 그러나 500 줄의 패치는 정확성을 검토하기 위하여

   몇시간이 걸릴 수도 있다(걸리는 시간은 패치의 크기 혹은 다른 것에

   비례하여 기하급수적으로 늘어난다).

    간결하고 가장 뛰어난 답을 보길 원한다. 훌륭한 학생은 이것을 알고

    마지막으로 답을 얻기 전 중간 과정들을 제출하진 않는다.

    커널 개발도 마찬가지이다. 메인트너들과 검토하는 사람들은 문제를

    커널 개발도 마찬가지이다. 메인테이너들과 검토하는 사람들은 문제를

    풀어나가는 과정속에 숨겨진 과정을 보길 원하진 않는다. 그들은

    간결하고 멋진 답을 보길 원한다."

커뮤니티와 함께 일하며 뛰어난 답을 찾고 여러분들의 완성되지 않은 일들

사이에 균형을 유지해야 하는 어려움이 있을 수 있다. 그러므로 프로세스의

초반에 여러분의 일을 향상시키기위한 피드백을 얻는 것 뿐만 아니라

커뮤니티와 협력하며 뛰어난 답을 찾는 것과 여러분들의 끝마치지 못한 작업들

사이에 균형을 유지해야 하는 것은 어려울지도 모른다. 그러므로 프로세스의

초반에 여러분의 작업을 향상시키기위한 피드백을 얻는 것 뿐만 아니라

여러분들의 변경들을 작은 묶음으로 유지해서 심지어는 여러분의 작업의

모든 부분이 지금은 포함될 준비가 되어있지 않지만 작은 부분은 이미

모든 부분이 지금은 포함될 준비가 되어있지 않지만 작은 부분은 벌써

받아들여질 수 있도록 유지하는 것이 바람직하다.

또한 완성되지 않았고 "나중에 수정될 것이다." 와 같은 것들은 포함하는

또한 완성되지 않았고 "나중에 수정될 것이다." 와 같은 것들을 포함하는

패치들은 받아들여지지 않을 것이라는 점을 유념하라.

변경을 정당화해라

여러분들의 나누어진 패치들을 리눅스 커뮤니티가 왜 반영해야 하는지를

알도록 하는 것은 매우 중요하다. 새로운 기능들이 필요하고 유용하다는

것은 반드시 그에 맞는 이유가 있어야 한다.

것은 반드시 그에 합당한 이유가 있어야 한다.

변경을 문서화해라

것이다. 그리고 항상 그 내용을 보길 원하는 모든 사람들을 위해 보존될

것이다. 패치는 완벽하게 다음과 같은 내용들을 포함하여 설명해야 한다.

  - 변경이 왜 필요한지

  - 패치에 관한 전체 설계 어프로치

  - 패치에 관한 전체 설계 접근(approach)

  - 구현 상세들

  - 테스트 결과들

이 모든 것을 하는 것은 매우 어려운 일이다. 완벽히 소화하는 데는 적어도 몇년이

걸릴 수도 있다. 많은 인내와 결의가 필요한 계속되는 개선의 과정이다. 그러나

걸릴 수도 있다. 많은 인내와 결심이 필요한 계속되는 개선의 과정이다. 그러나

가능한한 포기하지 말라. 많은 사람들은 이전부터 해왔던 것이고 그 사람들도

정확하게 여러분들이 지금 서 있는 그 곳부터  시작했었다.

메인트너: Greg Kroah-Hartman <greg@kroah.com>

메인테이너: Greg Kroah-Hartman <greg@kroah.com>