diff options
Diffstat (limited to 'Documentation/translations')
12 files changed, 700 insertions, 176 deletions
diff --git a/Documentation/translations/it_IT/process/coding-style.rst b/Documentation/translations/it_IT/process/coding-style.rst index 8995d2d19f20..8725f2b9e960 100644 --- a/Documentation/translations/it_IT/process/coding-style.rst +++ b/Documentation/translations/it_IT/process/coding-style.rst @@ -1005,7 +1005,7 @@ struttura, usate .. code-block:: c - #define FIELD_SIZEOF(t, f) (sizeof(((t*)0)->f)) + #define sizeof_field(t, f) (sizeof(((t*)0)->f)) Ci sono anche le macro min() e max() che, se vi serve, effettuano un controllo rigido sui tipi. Sentitevi liberi di leggere attentamente questo file diff --git a/Documentation/translations/it_IT/process/magic-number.rst b/Documentation/translations/it_IT/process/magic-number.rst index ed1121d0ba84..783e0de314a0 100644 --- a/Documentation/translations/it_IT/process/magic-number.rst +++ b/Documentation/translations/it_IT/process/magic-number.rst @@ -87,7 +87,6 @@ FF_MAGIC 0x4646 fc_info ``drivers/net/ip ISICOM_MAGIC 0x4d54 isi_port ``include/linux/isicom.h`` PTY_MAGIC 0x5001 ``drivers/char/pty.c`` PPP_MAGIC 0x5002 ppp ``include/linux/if_pppvar.h`` -SERIAL_MAGIC 0x5301 async_struct ``include/linux/serial.h`` SSTATE_MAGIC 0x5302 serial_state ``include/linux/serial.h`` SLIP_MAGIC 0x5302 slip ``drivers/net/slip.h`` STRIP_MAGIC 0x5303 strip ``drivers/net/strip.c`` diff --git a/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst b/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst index 118fb4153e8f..f3c8e8d377ee 100644 --- a/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst +++ b/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst @@ -455,7 +455,7 @@ soluzioni disponibili: `GnuK`_ della FSIJ. Questo è uno dei pochi dispositivi a supportare le chiavi ECC ED25519, ma offre meno funzionalità di sicurezza (come la resistenza alla manomissione o alcuni attacchi ad un canale laterale). -- `Nitrokey Pro`_: è simile alla Nitrokey Start, ma è più resistente alla +- `Nitrokey Pro 2`_: è simile alla Nitrokey Start, ma è più resistente alla manomissione e offre più funzionalità di sicurezza. La Pro 2 supporta la crittografia ECC (NISTP). - `Yubikey 5`_: l'hardware e il software sono proprietari, ma è più economica diff --git a/Documentation/translations/ko_KR/howto.rst b/Documentation/translations/ko_KR/howto.rst index b3f51b19de7c..ae3ad897d2ae 100644 --- a/Documentation/translations/ko_KR/howto.rst +++ b/Documentation/translations/ko_KR/howto.rst @@ -240,21 +240,21 @@ ReST 마크업을 사용하는 문서들은 Documentation/output 에 생성된 서브시스템에 특화된 커널 브랜치들로 구성된다. 몇몇 다른 메인 브랜치들은 다음과 같다. - - main 4.x 커널 트리 - - 4.x.y - 안정된 커널 트리 - - 서브시스템을 위한 커널 트리들과 패치들 - - 4.x - 통합 테스트를 위한 next 커널 트리 + - 리누스의 메인라인 트리 + - 여러 메이저 넘버를 갖는 다양한 안정된 커널 트리들 + - 서브시스템을 위한 커널 트리들 + - 통합 테스트를 위한 linux-next 커널 트리 -4.x 커널 트리 +메인라인 트리 ~~~~~~~~~~~~~ -4.x 커널들은 Linus Torvalds가 관리하며 https://kernel.org 의 -pub/linux/kernel/v4.x/ 디렉토리에서 참조될 수 있다.개발 프로세스는 다음과 같다. +메인라인 트리는 Linus Torvalds가 관리하며 https://kernel.org 또는 소스 +저장소에서 참조될 수 있다.개발 프로세스는 다음과 같다. - 새로운 커널이 배포되자마자 2주의 시간이 주어진다. 이 기간동은 메인테이너들은 큰 diff들을 Linus에게 제출할 수 있다. 대개 이 패치들은 - 몇 주 동안 -next 커널내에 이미 있었던 것들이다. 큰 변경들을 제출하는 데 - 선호되는 방법은 git(커널의 소스 관리 툴, 더 많은 정보들은 + 몇 주 동안 linux-next 커널내에 이미 있었던 것들이다. 큰 변경들을 제출하는 + 데 선호되는 방법은 git(커널의 소스 관리 툴, 더 많은 정보들은 https://git-scm.com/ 에서 참조할 수 있다)를 사용하는 것이지만 순수한 패치파일의 형식으로 보내는 것도 무관하다. - 2주 후에 -rc1 커널이 릴리즈되며 여기서부터의 주안점은 새로운 커널을 @@ -281,28 +281,25 @@ Andrew Morton의 글이 있다. 버그의 상황에 따라 배포되는 것이지 미리정해 놓은 시간에 따라 배포되는 것은 아니기 때문이다."* -4.x.y - 안정 커널 트리 -~~~~~~~~~~~~~~~~~~~~~~ +여러 메이저 넘버를 갖는 다양한 안정된 커널 트리들 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -3 자리 숫자로 이루어진 버젼의 커널들은 -stable 커널들이다. 그것들은 4.x -커널에서 발견된 큰 회귀들이나 보안 문제들 중 비교적 작고 중요한 수정들을 -포함한다. +3 자리 숫자로 이루어진 버젼의 커널들은 -stable 커널들이다. 그것들은 해당 메이저 +메인라인 릴리즈에서 발견된 큰 회귀들이나 보안 문제들 중 비교적 작고 중요한 +수정들을 포함하며, 앞의 두 버전 넘버는 같은 기반 버전을 의미한다. 이것은 가장 최근의 안정적인 커널을 원하는 사용자에게 추천되는 브랜치이며, 개발/실험적 버젼을 테스트하는 것을 돕고자 하는 사용자들과는 별로 관련이 없다. -어떤 4.x.y 커널도 사용할 수 없다면 그때는 가장 높은 숫자의 4.x -커널이 현재의 안정 커널이다. - -4.x.y는 "stable" 팀<stable@vger.kernel.org>에 의해 관리되며 거의 매번 격주로 -배포된다. +-stable 트리들은 "stable" 팀<stable@vger.kernel.org>에 의해 관리되며 거의 매번 +격주로 배포된다. 커널 트리 문서들 내의 :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>` 파일은 어떤 종류의 변경들이 -stable 트리로 들어왔는지와 배포 프로세스가 어떻게 진행되는지를 설명한다. -서브시스템 커널 트리들과 패치들 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +서브시스템 커널 트리들 +~~~~~~~~~~~~~~~~~~~~~~ 다양한 커널 서브시스템의 메인테이너들 --- 그리고 많은 커널 서브시스템 개발자들 --- 은 그들의 현재 개발 상태를 소스 저장소로 노출한다. 이를 통해 다른 사람들도 @@ -324,17 +321,18 @@ Andrew Morton의 글이 있다. 대부분의 이러한 patchwork 사이트는 https://patchwork.kernel.org/ 또는 http://patchwork.ozlabs.org/ 에 나열되어 있다. -4.x - 통합 테스트를 위한 next 커널 트리 ---------------------------------------- -서브시스템 트리들의 변경사항들은 mainline 4.x 트리로 들어오기 전에 통합 -테스트를 거쳐야 한다. 이런 목적으로, 모든 서브시스템 트리의 변경사항을 거의 -매일 받아가는 특수한 테스트 저장소가 존재한다: +통합 테스트를 위한 linux-next 커널 트리 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +서브시스템 트리들의 변경사항들은 mainline 트리로 들어오기 전에 통합 테스트를 +거쳐야 한다. 이런 목적으로, 모든 서브시스템 트리의 변경사항을 거의 매일 +받아가는 특수한 테스트 저장소가 존재한다: https://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git -이런 식으로, -next 커널을 통해 다음 머지 기간에 메인라인 커널에 어떤 변경이 -가해질 것인지 간략히 알 수 있다. 모험심 강한 테스터라면 -next 커널에서 테스트를 -수행하는 것도 좋을 것이다. +이런 식으로, linux-next 커널을 통해 다음 머지 기간에 메인라인 커널에 어떤 +변경이 가해질 것인지 간략히 알 수 있다. 모험심 강한 테스터라면 linux-next +커널에서 테스트를 수행하는 것도 좋을 것이다. 버그 보고 diff --git a/Documentation/translations/ko_KR/index.rst b/Documentation/translations/ko_KR/index.rst index 0b695345abc7..27995c4233de 100644 --- a/Documentation/translations/ko_KR/index.rst +++ b/Documentation/translations/ko_KR/index.rst @@ -3,8 +3,8 @@ \renewcommand\thesection* \renewcommand\thesubsection* -Korean translations -=================== +한국어 번역 +=========== .. toctree:: :maxdepth: 1 diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt index 2774624ee843..2e831ece6e26 100644 --- a/Documentation/translations/ko_KR/memory-barriers.txt +++ b/Documentation/translations/ko_KR/memory-barriers.txt @@ -1907,21 +1907,6 @@ Mandatory 배리어들은 SMP 시스템에서도 UP 시스템에서도 SMP 효 위해선 Documentation/DMA-API.txt 문서를 참고하세요. -MMIO 쓰기 배리어 ----------------- - -리눅스 커널은 또한 memory-mapped I/O 쓰기를 위한 특별한 배리어도 가지고 -있습니다: - - mmiowb(); - -이것은 mandatory 쓰기 배리어의 변종으로, 완화된 순서 규칙의 I/O 영역에으로의 -쓰기가 부분적으로 순서를 맞추도록 해줍니다. 이 함수는 CPU->하드웨어 사이를 -넘어서 실제 하드웨어에까지 일부 수준의 영향을 끼칩니다. - -더 많은 정보를 위해선 "Acquire vs I/O 액세스" 서브섹션을 참고하세요. - - ========================= 암묵적 커널 메모리 배리어 ========================= @@ -2283,73 +2268,6 @@ ACQUIRE VS 메모리 액세스 *E, *F or *G following RELEASE Q - -ACQUIRE VS I/O 액세스 ----------------------- - -특정한 (특히 NUMA 가 관련된) 환경 하에서 두개의 CPU 에서 동일한 스핀락으로 -보호되는 두개의 크리티컬 섹션 안의 I/O 액세스는 PCI 브릿지에 겹쳐진 I/O -액세스로 보일 수 있는데, PCI 브릿지는 캐시 일관성 프로토콜과 합을 맞춰야 할 -의무가 없으므로, 필요한 읽기 메모리 배리어가 요청되지 않기 때문입니다. - -예를 들어서: - - CPU 1 CPU 2 - =============================== =============================== - spin_lock(Q) - writel(0, ADDR) - writel(1, DATA); - spin_unlock(Q); - spin_lock(Q); - writel(4, ADDR); - writel(5, DATA); - spin_unlock(Q); - -는 PCI 브릿지에 다음과 같이 보일 수 있습니다: - - STORE *ADDR = 0, STORE *ADDR = 4, STORE *DATA = 1, STORE *DATA = 5 - -이렇게 되면 하드웨어의 오동작을 일으킬 수 있습니다. - - -이런 경우엔 잡아둔 스핀락을 내려놓기 전에 mmiowb() 를 수행해야 하는데, 예를 -들면 다음과 같습니다: - - CPU 1 CPU 2 - =============================== =============================== - spin_lock(Q) - writel(0, ADDR) - writel(1, DATA); - mmiowb(); - spin_unlock(Q); - spin_lock(Q); - writel(4, ADDR); - writel(5, DATA); - mmiowb(); - spin_unlock(Q); - -이 코드는 CPU 1 에서 요청된 두개의 스토어가 PCI 브릿지에 CPU 2 에서 요청된 -스토어들보다 먼저 보여짐을 보장합니다. - - -또한, 같은 디바이스에서 스토어를 이어 로드가 수행되면 이 로드는 로드가 수행되기 -전에 스토어가 완료되기를 강제하므로 mmiowb() 의 필요가 없어집니다: - - CPU 1 CPU 2 - =============================== =============================== - spin_lock(Q) - writel(0, ADDR) - a = readl(DATA); - spin_unlock(Q); - spin_lock(Q); - writel(4, ADDR); - b = readl(DATA); - spin_unlock(Q); - - -더 많은 정보를 위해선 Documentation/driver-api/device-io.rst 를 참고하세요. - - ========================= 메모리 배리어가 필요한 곳 ========================= @@ -2494,14 +2412,9 @@ _않습니다_. 리눅스 커널 내부에서, I/O 는 어떻게 액세스들을 적절히 순차적이게 만들 수 있는지 알고 있는, - inb() 나 writel() 과 같은 - 적절한 액세스 루틴을 통해 이루어져야만 합니다. 이것들은 대부분의 경우에는 명시적 메모리 배리어 와 함께 사용될 필요가 -없습니다만, 다음의 두가지 상황에서는 명시적 메모리 배리어가 필요할 수 있습니다: - - (1) 일부 시스템에서 I/O 스토어는 모든 CPU 에 일관되게 순서 맞춰지지 않는데, - 따라서 _모든_ 일반적인 드라이버들에 락이 사용되어야만 하고 이 크리티컬 - 섹션을 빠져나오기 전에 mmiowb() 가 꼭 호출되어야 합니다. - - (2) 만약 액세스 함수들이 완화된 메모리 액세스 속성을 갖는 I/O 메모리 윈도우를 - 사용한다면, 순서를 강제하기 위해선 _mandatory_ 메모리 배리어가 필요합니다. +없습니다만, 완화된 메모리 액세스 속성으로 I/O 메모리 윈도우로의 참조를 위해 +액세스 함수가 사용된다면 순서를 강제하기 위해 _mandatory_ 메모리 배리어가 +필요합니다. 더 많은 정보를 위해선 Documentation/driver-api/device-io.rst 를 참고하십시오. @@ -2545,10 +2458,9 @@ _않습니다_. 인터럽트 내에서 일어난 액세스와 섞일 수 있다고 - 그리고 그 반대도 - 가정해야만 합니다. -그런 영역 안에서 일어나는 I/O 액세스들은 엄격한 순서 규칙의 I/O 레지스터에 -묵시적 I/O 배리어를 형성하는 동기적 (synchronous) 로드 오퍼레이션을 포함하기 -때문에 일반적으로는 이런게 문제가 되지 않습니다. 만약 이걸로는 충분치 않다면 -mmiowb() 가 명시적으로 사용될 필요가 있습니다. +그런 영역 안에서 일어나는 I/O 액세스는 묵시적 I/O 배리어를 형성하는, 엄격한 +순서 규칙의 I/O 레지스터로의 로드 오퍼레이션을 포함하기 때문에 일반적으로는 +문제가 되지 않습니다. 하나의 인터럽트 루틴과 별도의 CPU 에서 수행중이며 서로 통신을 하는 두 루틴 @@ -2560,67 +2472,102 @@ mmiowb() 가 명시적으로 사용될 필요가 있습니다. 커널 I/O 배리어의 효과 ====================== -I/O 메모리에 액세스할 때, 드라이버는 적절한 액세스 함수를 사용해야 합니다: +I/O 액세스를 통한 주변장치와의 통신은 아키텍쳐와 기기에 매우 종속적입니다. +따라서, 본질적으로 이식성이 없는 드라이버는 가능한 가장 적은 오버헤드로 +동기화를 하기 위해 각자의 타겟 시스템의 특정 동작에 의존할 겁니다. 다양한 +아키텍쳐와 버스 구현에 이식성을 가지려 하는 드라이버를 위해, 커널은 다양한 +정도의 순서 보장을 제공하는 일련의 액세스 함수를 제공합니다. - (*) inX(), outX(): - - 이것들은 메모리 공간보다는 I/O 공간에 이야기를 하려는 의도로 - 만들어졌습니다만, 그건 기본적으로 CPU 마다 다른 컨셉입니다. i386 과 - x86_64 프로세서들은 특별한 I/O 공간 액세스 사이클과 명령어를 실제로 가지고 - 있지만, 다른 많은 CPU 들에는 그런 컨셉이 존재하지 않습니다. - - 다른 것들 중에서도 PCI 버스가 I/O 공간 컨셉을 정의하는데, 이는 - i386 과 - x86_64 같은 CPU 에서 - CPU 의 I/O 공간 컨셉으로 쉽게 매치됩니다. 하지만, - 대체할 I/O 공간이 없는 CPU 에서는 CPU 의 메모리 맵의 가상 I/O 공간으로 - 매핑될 수도 있습니다. - - 이 공간으로의 액세스는 (i386 등에서는) 완전하게 동기화 됩니다만, 중간의 - (PCI 호스트 브리지와 같은) 브리지들은 이를 완전히 보장하진 않을수도 - 있습니다. + (*) readX(), writeX(): - 이것들의 상호간의 순서는 완전하게 보장됩니다. + readX() 와 writeX() MMIO 액세스 함수는 접근되는 주변장치로의 포인터를 + __iomem * 패러미터로 받습니다. 디폴트 I/O 기능으로 매핑되는 포인터 + (예: ioremap() 으로 반환되는 것) 의 순서 보장은 다음과 같습니다: + + 1. 같은 주변장치로의 모든 readX() 와 writeX() 액세스는 각자에 대해 + 순서지어집니다. 이는 같은 CPU 쓰레드에 의한 특정 디바이스로의 MMIO + 레지스터 액세스가 프로그램 순서대로 도착할 것을 보장합니다. + + 2. 한 스핀락을 잡은 CPU 쓰레드에 의한 writeX() 는 같은 스핀락을 나중에 + 잡은 다른 CPU 쓰레드에 의해 같은 주변장치를 향해 호출된 writeX() + 앞으로 순서지어집니다. 이는 스핀락을 잡은 채 특정 디바이스를 향해 + 호출된 MMIO 레지스터 쓰기는 해당 락의 획득에 일관적인 순서로 도달할 + 것을 보장합니다. + + 3. 특정 주변장치를 향한 특정 CPU 쓰레드의 writeX() 는 먼저 해당 + 쓰레드로 전파되는, 또는 해당 쓰레드에 의해 요청된 모든 앞선 메모리 + 쓰기가 완료되기 전까지 먼저 기다립니다. 이는 dma_alloc_coherent() + 를 통해 할당된 전송용 DMA 버퍼로의 해당 CPU 의 쓰기가 이 CPU 가 이 + 전송을 시작시키기 위해 MMIO 컨트롤 레지스터에 쓰기를 할 때 DMA + 엔진에 보여질 것을 보장합니다. + + 4. 특정 CPU 쓰레드에 의한 주변장치로의 readX() 는 같은 쓰레드에 의한 + 모든 뒤따르는 메모리 읽기가 시작되기 전에 완료됩니다. 이는 + dma_alloc_coherent() 를 통해 할당된 수신용 DMA 버퍼로부터의 CPU 의 + 읽기는 이 DMA 수신의 완료를 표시하는 DMA 엔진의 MMIO 상태 레지스터 + 읽기 후에는 오염된 데이터를 읽지 않을 것을 보장합니다. + + 5. CPU 에 의한 주변장치로의 readX() 는 모든 뒤따르는 delay() 루프가 + 수행을 시작하기 전에 완료됩니다. 이는 CPU 의 특정 + 주변장치로의 두개의 MMIO 레지스터 쓰기가 행해지는데 첫번째 쓰기가 + readX() 를 통해 곧바로 읽어졌고 이어 두번째 writeX() 전에 udelay(1) + 이 호출되었다면 이 두개의 쓰기는 최소 1us 의 간격을 두고 행해질 것을 + 보장합니다: + + writel(42, DEVICE_REGISTER_0); // 디바이스에 도착함... + readl(DEVICE_REGISTER_0); + udelay(1); + writel(42, DEVICE_REGISTER_1); // ...이것보다 최소 1us 전에. + + 디폴트가 아닌 기능을 통해 얻어지는 __iomem 포인터 (예: ioremap_wc() 를 + 통해 리턴되는 것) 의 순서 속성은 실제 아키텍쳐에 의존적이어서 이런 + 종류의 매핑으로의 액세스는 앞서 설명된 보장사항에 의존할 수 없습니다. - 다른 타입의 메모리 오퍼레이션, I/O 오퍼레이션에 대한 순서는 완전하게 - 보장되지는 않습니다. + (*) readX_relaxed(), writeX_relaxed() - (*) readX(), writeX(): + 이것들은 readX() 와 writeX() 랑 비슷하지만, 더 완화된 메모리 순서 + 보장을 제공합니다. 구체적으로, 이것들은 일반적 메모리 액세스나 delay() + 루프 (예:앞의 2-5 항목) 에 대해 순서를 보장하지 않습니다만 디폴트 I/O + 기능으로 매핑된 __iomem 포인터에 대해 동작할 때, 같은 CPU 쓰레드에 의한 + 같은 주변장치로의 액세스에는 순서가 맞춰질 것이 보장됩니다. - 이것들이 수행 요청되는 CPU 에서 서로에게 완전히 순서가 맞춰지고 독립적으로 - 수행되는지에 대한 보장 여부는 이들이 액세스 하는 메모리 윈도우에 정의된 - 특성에 의해 결정됩니다. 예를 들어, 최신의 i386 아키텍쳐 머신에서는 MTRR - 레지스터로 이 특성이 조정됩니다. + (*) readsX(), writesX(): - 일반적으로는, 프리페치 (prefetch) 가능한 디바이스를 액세스 하는게 - 아니라면, 이것들은 완전히 순서가 맞춰지고 결합되지 않게 보장될 겁니다. + readsX() 와 writesX() MMIO 액세스 함수는 DMA 를 수행하는데 적절치 않은, + 주변장치 내의 메모리 매핑된 레지스터 기반 FIFO 로의 액세스를 위해 + 설계되었습니다. 따라서, 이 기능들은 앞서 설명된 readX_relaxed() 와 + writeX_relaxed() 의 순서 보장만을 제공합니다. - 하지만, (PCI 브리지와 같은) 중간의 하드웨어는 자신이 원한다면 집행을 - 연기시킬 수 있습니다; 스토어 명령을 실제로 하드웨어로 내려보내기(flush) - 위해서는 같은 위치로부터 로드를 하는 방법이 있습니다만[*], PCI 의 경우는 - 같은 디바이스나 환경 구성 영역에서의 로드만으로도 충분할 겁니다. + (*) inX(), outX(): - [*] 주의! 쓰여진 것과 같은 위치로부터의 로드를 시도하는 것은 오동작을 - 일으킬 수도 있습니다 - 예로 16650 Rx/Tx 시리얼 레지스터를 생각해 - 보세요. + inX() 와 outX() 액세스 함수는 일부 아키텍쳐 (특히 x86) 에서는 특수한 + 명령어를 필요로 하며 포트에 매핑되는, 과거의 유산인 I/O 주변장치로의 + 접근을 위해 만들어졌습니다. - 프리페치 가능한 I/O 메모리가 사용되면, 스토어 명령들이 순서를 지키도록 - 하기 위해 mmiowb() 배리어가 필요할 수 있습니다. + 많은 CPU 아키텍쳐가 결국은 이런 주변장치를 내부의 가상 메모리 매핑을 + 통해 접근하기 때문에, inX() 와 outX() 가 제공하는 이식성 있는 순서 + 보장은 디폴트 I/O 기능을 통한 매핑을 접근할 때의 readX() 와 writeX() 에 + 의해 제공되는 것과 각각 동일합니다. - PCI 트랜잭션 사이의 상호작용에 대해 더 많은 정보를 위해선 PCI 명세서를 - 참고하시기 바랍니다. + 디바이스 드라이버는 outX() 가 리턴하기 전에 해당 I/O 주변장치로부터의 + 완료 응답을 기다리는 쓰기 트랜잭션을 만들어 낸다고 기대할 수도 + 있습니다. 이는 모든 아키텍쳐에서 보장되지는 않고, 따라서 이식성 있는 + 순서 규칙의 일부분이 아닙니다. - (*) readX_relaxed(), writeX_relaxed() + (*) insX(), outsX(): - 이것들은 readX() 와 writeX() 랑 비슷하지만, 더 완화된 메모리 순서 보장을 - 제공합니다. 구체적으로, 이것들은 일반적 메모리 액세스 (예: DMA 버퍼) 에도 - LOCK 이나 UNLOCK 오퍼레이션들에도 순서를 보장하지 않습니다. LOCK 이나 - UNLOCK 오퍼레이션들에 맞춰지는 순서가 필요하다면, mmiowb() 배리어가 사용될 - 수 있습니다. 같은 주변 장치에의 완화된 액세스끼리는 순서가 지켜짐을 알아 - 두시기 바랍니다. + 앞에서와 같이, insX() 와 outsX() 액세스 함수는 디폴트 I/O 기능을 통한 + 매핑을 접근할 때 각각 readX() 와 writeX() 와 같은 순서 보장을 + 제공합니다. (*) ioreadX(), iowriteX() - 이것들은 inX()/outX() 나 readX()/writeX() 처럼 실제로 수행하는 액세스의 - 종류에 따라 적절하게 수행될 것입니다. + 이것들은 inX()/outX() 나 readX()/writeX() 처럼 실제로 수행하는 액세스의 + 종류에 따라 적절하게 수행될 것입니다. + +String 액세스 함수 (insX(), outsX(), readsX() 그리고 writesX()) 의 예외를 +제외하고는, 앞의 모든 것이 아랫단의 주변장치가 little-endian 이라 가정하며, +따라서 big-endian 아키텍쳐에서는 byte-swapping 오퍼레이션을 수행합니다. =================================== diff --git a/Documentation/translations/zh_CN/process/coding-style.rst b/Documentation/translations/zh_CN/process/coding-style.rst index 4f6237392e65..eae10bc7f86f 100644 --- a/Documentation/translations/zh_CN/process/coding-style.rst +++ b/Documentation/translations/zh_CN/process/coding-style.rst @@ -826,7 +826,7 @@ inline gcc 也可以自动使其内联。而且其他用户可能会要求移除 .. code-block:: c - #define FIELD_SIZEOF(t, f) (sizeof(((t*)0)->f)) + #define sizeof_field(t, f) (sizeof(((t*)0)->f)) 还有可以做严格的类型检查的 min() 和 max() 宏，如果你需要可以使用它们。你可以 自己看看那个头文件里还定义了什么你可以拿来用的东西，如果有定义的话，你就不应 diff --git a/Documentation/translations/zh_CN/process/embargoed-hardware-issues.rst b/Documentation/translations/zh_CN/process/embargoed-hardware-issues.rst new file mode 100644 index 000000000000..b93f1af68261 --- /dev/null +++ b/Documentation/translations/zh_CN/process/embargoed-hardware-issues.rst @@ -0,0 +1,228 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: :ref:`Documentation/process/embargoed-hardware-issues.rst <embargoed_hardware_issues>` +:Translator: Alex Shi <alex.shi@linux.alibaba.com> + +被限制的硬件问题 +================ + +范围 +---- + +导致安全问题的硬件问题与只影响Linux内核的纯软件错误是不同的安全错误类别。 + +必须区别对待诸如熔毁(Meltdown)、Spectre、L1TF等硬件问题，因为它们通常会影响 +所有操作系统（“OS”），因此需要在不同的OS供应商、发行版、硬件供应商和其他各方 +之间进行协调。对于某些问题，软件缓解可能依赖于微码或固件更新，这需要进一步的 +协调。 + +.. _zh_Contact: + +接触 +---- + +Linux内核硬件安全小组独立于普通的Linux内核安全小组。 + +该小组只负责协调被限制的硬件安全问题。Linux内核中纯软件安全漏洞的报告不由该 +小组处理，报告者将被引导至常规Linux内核安全小组(:ref:`Documentation/admin-guide/ +<securitybugs>`)联系。 + +可以通过电子邮件 <hardware-security@kernel.org> 与小组联系。这是一份私密的安全 +官名单，他们将帮助您根据我们的文档化流程协调问题。 + +邮件列表是加密的，发送到列表的电子邮件可以通过PGP或S/MIME加密，并且必须使用报告 +者的PGP密钥或S/MIME证书签名。该列表的PGP密钥和S/MIME证书可从 +https://www.kernel.org/.... 获得。 + +虽然硬件安全问题通常由受影响的硬件供应商处理，但我们欢迎发现潜在硬件缺陷的研究 +人员或个人与我们联系。 + +硬件安全官 +^^^^^^^^^^ + +目前的硬件安全官小组: + + - Linus Torvalds（Linux基金会院士） + - Greg Kroah Hartman（Linux基金会院士） + - Thomas Gleixner（Linux基金会院士） + +邮件列表的操作 +^^^^^^^^^^^^^^ + +处理流程中使用的加密邮件列表托管在Linux Foundation的IT基础设施上。通过提供这项 +服务，Linux基金会的IT基础设施安全总监在技术上有能力访问被限制的信息，但根据他 +的雇佣合同，他必须保密。Linux基金会的IT基础设施安全总监还负责 kernel.org 基础 +设施。 + +Linux基金会目前的IT基础设施安全总监是 Konstantin Ryabitsev。 + +保密协议 +-------- + +Linux内核硬件安全小组不是正式的机构，因此无法签订任何保密协议。核心社区意识到 +这些问题的敏感性，并提供了一份谅解备忘录。 + +谅解备忘录 +---------- + +Linux内核社区深刻理解在不同操作系统供应商、发行商、硬件供应商和其他各方之间 +进行协调时，保持硬件安全问题处于限制状态的要求。 + +Linux内核社区在过去已经成功地处理了硬件安全问题，并且有必要的机制允许在限制 +限制下进行符合社区的开发。 + +Linux内核社区有一个专门的硬件安全小组负责初始联系，并监督在限制规则下处理 +此类问题的过程。 + +硬件安全小组确定开发人员（领域专家），他们将组成特定问题的初始响应小组。最初 +的响应小组可以引入更多的开发人员（领域专家）以最佳的技术方式解决这个问题。 + +所有相关开发商承诺遵守限制规定，并对收到的信息保密。违反承诺将导致立即从当前 +问题中排除，并从所有相关邮件列表中删除。此外，硬件安全小组还将把违反者排除在 +未来的问题之外。这一后果的影响在我们社区是一种非常有效的威慑。如果发生违规 +情况，硬件安全小组将立即通知相关方。如果您或任何人发现潜在的违规行为，请立即 +向硬件安全人员报告。 + +流程 +^^^^ + +由于Linux内核开发的全球分布式特性，面对面的会议几乎不可能解决硬件安全问题。 +由于时区和其他因素，电话会议很难协调，只能在绝对必要时使用。加密电子邮件已被 +证明是解决此类问题的最有效和最安全的通信方法。 + +开始披露 +"""""""" + +披露内容首先通过电子邮件联系Linux内核硬件安全小组。此初始联系人应包含问题的 +描述和任何已知受影响硬件的列表。如果您的组织制造或分发受影响的硬件，我们建议 +您也考虑哪些其他硬件可能会受到影响。 + +硬件安全小组将提供一个特定于事件的加密邮件列表，用于与报告者进行初步讨论、 +进一步披露和协调。 + +硬件安全小组将向披露方提供一份开发人员（领域专家）名单，在与开发人员确认他们 +将遵守本谅解备忘录和文件化流程后，应首先告知开发人员有关该问题的信息。这些开发 +人员组成初始响应小组，并在初始接触后负责处理问题。硬件安全小组支持响应小组， +但不一定参与缓解开发过程。 + +虽然个别开发人员可能通过其雇主受到保密协议的保护，但他们不能以Linux内核开发 +人员的身份签订个别保密协议。但是，他们将同意遵守这一书面程序和谅解备忘录。 + +披露方应提供已经或应该被告知该问题的所有其他实体的联系人名单。这有几个目的: + + - 披露的实体列表允许跨行业通信，例如其他操作系统供应商、硬件供应商等。 + + - 可联系已披露的实体，指定应参与缓解措施开发的专家。 + + - 如果需要处理某一问题的专家受雇于某一上市实体或某一上市实体的成员，则响应 + 小组可要求该实体披露该专家。这确保专家也是实体反应小组的一部分。 + +披露 +"""" + +披露方通过特定的加密邮件列表向初始响应小组提供详细信息。 + +根据我们的经验，这些问题的技术文档通常是一个足够的起点，最好通过电子邮件进行 +进一步的技术澄清。 + +缓解开发 +"""""""" + +初始响应小组设置加密邮件列表，或在适当的情况下重新修改现有邮件列表。 + +使用邮件列表接近于正常的Linux开发过程，并且在过去已经成功地用于为各种硬件安全 +问题开发缓解措施。 + +邮件列表的操作方式与正常的Linux开发相同。发布、讨论和审查修补程序，如果同意， +则应用于非公共git存储库，参与开发人员只能通过安全连接访问该存储库。存储库包含 +针对主线内核的主开发分支，并根据需要为稳定的内核版本提供向后移植分支。 + +最初的响应小组将根据需要从Linux内核开发人员社区中确定更多的专家。引进专家可以 +在开发过程中的任何时候发生，需要及时处理。 + +如果专家受雇于披露方提供的披露清单上的实体或其成员，则相关实体将要求其参与。 + +否则，披露方将被告知专家参与的情况。谅解备忘录涵盖了专家，要求披露方确认参与。 +如果披露方有令人信服的理由提出异议，则必须在五个工作日内提出异议，并立即与事件 +小组解决。如果披露方在五个工作日内未作出回应，则视为默许。 + +在确认或解决异议后，专家由事件小组披露，并进入开发过程。 + +协调发布 +"""""""" + +有关各方将协商限制结束的日期和时间。此时，准备好的缓解措施集成到相关的内核树中 +并发布。 + +虽然我们理解硬件安全问题需要协调限制时间，但限制时间应限制在所有有关各方制定、 +测试和准备缓解措施所需的最短时间内。人为地延长限制时间以满足会议讨论日期或其他 +非技术原因，会给相关的开发人员和响应小组带来了更多的工作和负担，因为补丁需要 +保持最新，以便跟踪正在进行的上游内核开发，这可能会造成冲突的更改。 + +CVE分配 +""""""" + +硬件安全小组和初始响应小组都不分配CVE，开发过程也不需要CVE。如果CVE是由披露方 +提供的，则可用于文档中。 + +流程专使 +-------- + +为了协助这一进程，我们在各组织设立了专使，他们可以回答有关报告流程和进一步处理 +的问题或提供指导。专使不参与特定问题的披露，除非响应小组或相关披露方提出要求。 +现任专使名单: + + ============= ======================================================== + ARM + AMD Tom Lendacky <tom.lendacky@amd.com> + IBM + Intel Tony Luck <tony.luck@intel.com> + Qualcomm Trilok Soni <tsoni@codeaurora.org> + + Microsoft Sasha Levin <sashal@kernel.org> + VMware + Xen Andrew Cooper <andrew.cooper3@citrix.com> + + Canonical Tyler Hicks <tyhicks@canonical.com> + Debian Ben Hutchings <ben@decadent.org.uk> + Oracle Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> + Red Hat Josh Poimboeuf <jpoimboe@redhat.com> + SUSE Jiri Kosina <jkosina@suse.cz> + + Amazon + Google Kees Cook <keescook@chromium.org> + ============= ======================================================== + +如果要将您的组织添加到专使名单中，请与硬件安全小组联系。被提名的专使必须完全 +理解和支持我们的过程，并且在Linux内核社区中很容易联系。 + +加密邮件列表 +------------ + +我们使用加密邮件列表进行通信。这些列表的工作原理是，发送到列表的电子邮件使用 +列表的PGP密钥或列表的/MIME证书进行加密。邮件列表软件对电子邮件进行解密，并 +使用订阅者的PGP密钥或S/MIME证书为每个订阅者分别对其进行重新加密。有关邮件列表 +软件和用于确保列表安全和数据保护的设置的详细信息，请访问: +https://www.kernel.org/.... + +关键点 +^^^^^^ + +初次接触见 :ref:`zh_Contact`. 对于特定于事件的邮件列表，密钥和S/MIME证书通过 +特定列表发送的电子邮件传递给订阅者。 + +订阅事件特定列表 +^^^^^^^^^^^^^^^^ + +订阅由响应小组处理。希望参与通信的披露方将潜在订户的列表发送给响应组，以便 +响应组可以验证订阅请求。 + +每个订户都需要通过电子邮件向响应小组发送订阅请求。电子邮件必须使用订阅服务器 +的PGP密钥或S/MIME证书签名。如果使用PGP密钥，则必须从公钥服务器获得该密钥， +并且理想情况下该密钥连接到Linux内核的PGP信任网。另请参见: +https://www.kernel.org/signature.html. + +响应小组验证订阅者，并将订阅者添加到列表中。订阅后，订阅者将收到来自邮件列表 +的电子邮件，该邮件列表使用列表的PGP密钥或列表的/MIME证书签名。订阅者的电子邮件 +客户端可以从签名中提取PGP密钥或S/MIME证书，以便订阅者可以向列表发送加密电子 +邮件。 diff --git a/Documentation/translations/zh_CN/process/index.rst b/Documentation/translations/zh_CN/process/index.rst index be1e764a80d2..8051a7b322c5 100644 --- a/Documentation/translations/zh_CN/process/index.rst +++ b/Documentation/translations/zh_CN/process/index.rst @@ -31,6 +31,8 @@ development-process email-clients license-rules + kernel-enforcement-statement + kernel-driver-statement 其它大多数开发人员感兴趣的社区指南： @@ -43,6 +45,7 @@ stable-api-nonsense stable-kernel-rules management-style + embargoed-hardware-issues 这些是一些总体技术指南，由于缺乏更好的地方，现在已经放在这里 diff --git a/Documentation/translations/zh_CN/process/kernel-driver-statement.rst b/Documentation/translations/zh_CN/process/kernel-driver-statement.rst new file mode 100644 index 000000000000..2b3375bcccfd --- /dev/null +++ b/Documentation/translations/zh_CN/process/kernel-driver-statement.rst @@ -0,0 +1,199 @@ +.. _cn_process_statement_driver: + +.. include:: ../disclaimer-zh_CN.rst + +:Original: :ref:`Documentation/process/kernel-driver-statement.rst <process_statement_driver>` +:Translator: Alex Shi <alex.shi@linux.alibaba.com> + +内核驱动声明 +------------ + +关于Linux内核模块的立场声明 +=========================== + +我们，以下署名的Linux内核开发人员，认为任何封闭源Linux内核模块或驱动程序都是 +有害的和不可取的。我们已经一再发现它们对Linux用户，企业和更大的Linux生态系统 +有害。这样的模块否定了Linux开发模型的开放性，稳定性，灵活性和可维护性，并使 +他们的用户无法使用Linux社区的专业知识。提供闭源内核模块的供应商迫使其客户 +放弃Linux的主要优势或选择新的供应商。因此，为了充分利用开源所提供的成本节省和 +共享支持优势，我们敦促供应商采取措施，以开源内核代码在Linux上为其客户提供支持。 + +我们只为自己说话，而不是我们今天可能会为之工作，过去或将来会为之工作的任何公司。 + + - Dave Airlie + - Nick Andrew + - Jens Axboe + - Ralf Baechle + - Felipe Balbi + - Ohad Ben-Cohen + - Muli Ben-Yehuda + - Jiri Benc + - Arnd Bergmann + - Thomas Bogendoerfer + - Vitaly Bordug + - James Bottomley + - Josh Boyer + - Neil Brown + - Mark Brown + - David Brownell + - Michael Buesch + - Franck Bui-Huu + - Adrian Bunk + - François Cami + - Ralph Campbell + - Luiz Fernando N. Capitulino + - Mauro Carvalho Chehab + - Denis Cheng + - Jonathan Corbet + - Glauber Costa + - Alan Cox + - Magnus Damm + - Ahmed S. Darwish + - Robert P. J. Day + - Hans de Goede + - Arnaldo Carvalho de Melo + - Helge Deller + - Jean Delvare + - Mathieu Desnoyers + - Sven-Thorsten Dietrich + - Alexey Dobriyan + - Daniel Drake + - Alex Dubov + - Randy Dunlap + - Michael Ellerman + - Pekka Enberg + - Jan Engelhardt + - Mark Fasheh + - J. Bruce Fields + - Larry Finger + - Jeremy Fitzhardinge + - Mike Frysinger + - Kumar Gala + - Robin Getz + - Liam Girdwood + - Jan-Benedict Glaw + - Thomas Gleixner + - Brice Goglin + - Cyrill Gorcunov + - Andy Gospodarek + - Thomas Graf + - Krzysztof Halasa + - Harvey Harrison + - Stephen Hemminger + - Michael Hennerich + - Tejun Heo + - Benjamin Herrenschmidt + - Kristian Høgsberg + - Henrique de Moraes Holschuh + - Marcel Holtmann + - Mike Isely + - Takashi Iwai + - Olof Johansson + - Dave Jones + - Jesper Juhl + - Matthias Kaehlcke + - Kenji Kaneshige + - Jan Kara + - Jeremy Kerr + - Russell King + - Olaf Kirch + - Roel Kluin + - Hans-Jürgen Koch + - Auke Kok + - Peter Korsgaard + - Jiri Kosina + - Aaro Koskinen + - Mariusz Kozlowski + - Greg Kroah-Hartman + - Michael Krufky + - Aneesh Kumar + - Clemens Ladisch + - Christoph Lameter + - Gunnar Larisch + - Anders Larsen + - Grant Likely + - John W. Linville + - Yinghai Lu + - Tony Luck + - Pavel Machek + - Matt Mackall + - Paul Mackerras + - Roland McGrath + - Patrick McHardy + - Kyle McMartin + - Paul Menage + - Thierry Merle + - Eric Miao + - Akinobu Mita + - Ingo Molnar + - James Morris + - Andrew Morton + - Paul Mundt + - Oleg Nesterov + - Luca Olivetti + - S.Çağlar Onur + - Pierre Ossman + - Keith Owens + - Venkatesh Pallipadi + - Nick Piggin + - Nicolas Pitre + - Evgeniy Polyakov + - Richard Purdie + - Mike Rapoport + - Sam Ravnborg + - Gerrit Renker + - Stefan Richter + - David Rientjes + - Luis R. Rodriguez + - Stefan Roese + - Francois Romieu + - Rami Rosen + - Stephen Rothwell + - Maciej W. Rozycki + - Mark Salyzyn + - Yoshinori Sato + - Deepak Saxena + - Holger Schurig + - Amit Shah + - Yoshihiro Shimoda + - Sergei Shtylyov + - Kay Sievers + - Sebastian Siewior + - Rik Snel + - Jes Sorensen + - Alexey Starikovskiy + - Alan Stern + - Timur Tabi + - Hirokazu Takata + - Eliezer Tamir + - Eugene Teo + - Doug Thompson + - FUJITA Tomonori + - Dmitry Torokhov + - Marcelo Tosatti + - Steven Toth + - Theodore Tso + - Matthias Urlichs + - Geert Uytterhoeven + - Arjan van de Ven + - Ivo van Doorn + - Rik van Riel + - Wim Van Sebroeck + - Hans Verkuil + - Horst H. von Brand + - Dmitri Vorobiev + - Anton Vorontsov + - Daniel Walker + - Johannes Weiner + - Harald Welte + - Matthew Wilcox + - Dan J. Williams + - Darrick J. Wong + - David Woodhouse + - Chris Wright + - Bryan Wu + - Rafael J. Wysocki + - Herbert Xu + - Vlad Yasevich + - Peter Zijlstra + - Bartlomiej Zolnierkiewicz diff --git a/Documentation/translations/zh_CN/process/kernel-enforcement-statement.rst b/Documentation/translations/zh_CN/process/kernel-enforcement-statement.rst new file mode 100644 index 000000000000..75f7b7b9137c --- /dev/null +++ b/Documentation/translations/zh_CN/process/kernel-enforcement-statement.rst @@ -0,0 +1,151 @@ +.. _cn_process_statement_kernel: + +.. include:: ../disclaimer-zh_CN.rst + +:Original: :ref:`Documentation/process/kernel-enforcement-statement.rst <process_statement_kernel>` +:Translator: Alex Shi <alex.shi@linux.alibaba.com> + +Linux 内核执行声明 +------------------ + +作为Linux内核的开发人员，我们对如何使用我们的软件以及如何实施软件许可证有着 +浓厚的兴趣。遵守GPL-2.0的互惠共享义务对我们软件和社区的长期可持续性至关重要。 + +虽然有权强制执行对我们社区的贡献中的单独版权权益，但我们有共同的利益，即确保 +个人强制执行行动的方式有利于我们的社区，不会对我们软件生态系统的健康和增长 +产生意外的负面影响。为了阻止无益的执法行动，我们同意代表我们自己和我们版权 +利益的任何继承人对Linux内核用户作出以下符合我们开发社区最大利益的承诺: + + 尽管有GPL-2.0的终止条款，我们同意，采用以下GPL-3.0条款作为我们许可证下的 + 附加许可，作为任何对许可证下权利的非防御性主张，这符合我们开发社区的最佳 + 利益。 + + 但是，如果您停止所有违反本许可证的行为，则您从特定版权持有人处获得的 + 许可证将被恢复：（a）暂时恢复，除非版权持有人明确并最终终止您的许可证； + 以及（b）永久恢复, 如果版权持有人未能在你终止违反后60天内以合理方式 + 通知您违反本许可证的行为，则永久恢复您的许可证。 + + 此外，如果版权所有者以某种合理的方式通知您违反了本许可，这是您第一次 + 从该版权所有者处收到违反本许可的通知（对于任何作品），并且您在收到通知 + 后的30天内纠正违规行为。则您从特定版权所有者处获得的许可将永久恢复. + +我们提供这些保证的目的是鼓励更多地使用该软件。我们希望公司和个人使用、修改和 +分发此软件。我们希望以公开和透明的方式与用户合作，以消除我们对法规遵从性或强制 +执行的任何不确定性，这些不确定性可能会限制我们软件的采用。我们将法律行动视为 +最后手段，只有在其他社区努力未能解决这一问题时才采取行动。 + +最后，一旦一个不合规问题得到解决，我们希望用户会感到欢迎，加入我们为之努力的 +这个项目。共同努力，我们会更强大。 + +除了下面提到的以外，我们只为自己说话，而不是为今天、过去或将来可能为之工作的 +任何公司说话。 + + - Laura Abbott + - Bjorn Andersson (Linaro) + - Andrea Arcangeli + - Neil Armstrong + - Jens Axboe + - Pablo Neira Ayuso + - Khalid Aziz + - Ralf Baechle + - Felipe Balbi + - Arnd Bergmann + - Ard Biesheuvel + - Tim Bird + - Paolo Bonzini + - Christian Borntraeger + - Mark Brown (Linaro) + - Paul Burton + - Javier Martinez Canillas + - Rob Clark + - Kees Cook (Google) + - Jonathan Corbet + - Dennis Dalessandro + - Vivien Didelot (Savoir-faire Linux) + - Hans de Goede + - Mel Gorman (SUSE) + - Sven Eckelmann + - Alex Elder (Linaro) + - Fabio Estevam + - Larry Finger + - Bhumika Goyal + - Andy Gross + - Juergen Gross + - Shawn Guo + - Ulf Hansson + - Stephen Hemminger (Microsoft) + - Tejun Heo + - Rob Herring + - Masami Hiramatsu + - Michal Hocko + - Simon Horman + - Johan Hovold (Hovold Consulting AB) + - Christophe JAILLET + - Olof Johansson + - Lee Jones (Linaro) + - Heiner Kallweit + - Srinivas Kandagatla + - Jan Kara + - Shuah Khan (Samsung) + - David Kershner + - Jaegeuk Kim + - Namhyung Kim + - Colin Ian King + - Jeff Kirsher + - Greg Kroah-Hartman (Linux Foundation) + - Christian König + - Vinod Koul + - Krzysztof Kozlowski + - Viresh Kumar + - Aneesh Kumar K.V + - Julia Lawall + - Doug Ledford + - Chuck Lever (Oracle) + - Daniel Lezcano + - Shaohua Li + - Xin Long + - Tony Luck + - Catalin Marinas (Arm Ltd) + - Mike Marshall + - Chris Mason + - Paul E. McKenney + - Arnaldo Carvalho de Melo + - David S. Miller + - Ingo Molnar + - Kuninori Morimoto + - Trond Myklebust + - Martin K. Petersen (Oracle) + - Borislav Petkov + - Jiri Pirko + - Josh Poimboeuf + - Sebastian Reichel (Collabora) + - Guenter Roeck + - Joerg Roedel + - Leon Romanovsky + - Steven Rostedt (VMware) + - Frank Rowand + - Ivan Safonov + - Anna Schumaker + - Jes Sorensen + - K.Y. Srinivasan + - David Sterba (SUSE) + - Heiko Stuebner + - Jiri Kosina (SUSE) + - Willy Tarreau + - Dmitry Torokhov + - Linus Torvalds + - Thierry Reding + - Rik van Riel + - Luis R. Rodriguez + - Geert Uytterhoeven (Glider bvba) + - Eduardo Valentin (Amazon.com) + - Daniel Vetter + - Linus Walleij + - Richard Weinberger + - Dan Williams + - Rafael J. Wysocki + - Arvind Yadav + - Masahiro Yamada + - Wei Yongjun + - Lv Zheng + - Marc Zyngier (Arm Ltd) diff --git a/Documentation/translations/zh_CN/process/magic-number.rst b/Documentation/translations/zh_CN/process/magic-number.rst index 15c592518194..e4c225996af0 100644 --- a/Documentation/translations/zh_CN/process/magic-number.rst +++ b/Documentation/translations/zh_CN/process/magic-number.rst @@ -70,7 +70,6 @@ FF_MAGIC 0x4646 fc_info ``drivers/net/ip ISICOM_MAGIC 0x4d54 isi_port ``include/linux/isicom.h`` PTY_MAGIC 0x5001 ``drivers/char/pty.c`` PPP_MAGIC 0x5002 ppp ``include/linux/if_pppvar.h`` -SERIAL_MAGIC 0x5301 async_struct ``include/linux/serial.h`` SSTATE_MAGIC 0x5302 serial_state ``include/linux/serial.h`` SLIP_MAGIC 0x5302 slip ``drivers/net/slip.h`` STRIP_MAGIC 0x5303 strip ``drivers/net/strip.c`` |