* [PATCH 1/7] docs/memory-barriers.txt/kokr: Rewrite "KERNEL I/O BARRIER EFFECTS" section
2019-11-21 23:41 [PATCH 0/7] docs: Update ko_KR translations SeongJae Park
@ 2019-11-21 23:41 ` SeongJae Park
2019-11-21 23:41 ` [PATCH 2/7] Documentation/kokr: Kill all references to mmiowb() SeongJae Park
` (7 subsequent siblings)
8 siblings, 0 replies; 17+ messages in thread
From: SeongJae Park @ 2019-11-21 23:41 UTC (permalink / raw)
To: corbet, will, paulmck; +Cc: linux-kernel, linux-doc, SeongJae Park
Translate this commit to Korean:
4614bbdee357 ("docs/memory-barriers.txt: Rewrite "KERNEL I/O BARRIER EFFECTS" section")
Signed-off-by: SeongJae Park <sj38.park@gmail.com>
---
.../translations/ko_KR/memory-barriers.txt | 105 +++++++++++-------
1 file changed, 64 insertions(+), 41 deletions(-)
diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt
index 42509b86542f..11fb7254ba8d 100644
--- a/Documentation/translations/ko_KR/memory-barriers.txt
+++ b/Documentation/translations/ko_KR/memory-barriers.txt
@@ -2560,68 +2560,91 @@ mmiowb() 가 명시적으로 사용될 필요가 있습니다.
커널 I/O 배리어의 효과
======================
-I/O 메모리에 액세스할 때, 드라이버는 적절한 액세스 함수를 사용해야 합니다:
+I/O 액세스를 통한 주변장치와의 통신은 아키텍쳐와 기기에 매우 종속적입니다.
+따라서, 본질적으로 이식성이 없는 드라이버는 가능한 가장 적은 오버헤드로
+동기화를 하기 위해 각자의 타겟 시스템의 특정 동작에 의존할 겁니다. 다양한
+아키텍쳐와 버스 구현에 이식성을 가지려 하는 드라이버를 위해, 커널은 다양한
+정도의 순서 보장을 제공하는 일련의 액세스 함수를 제공합니다.
- (*) inX(), outX():
+ (*) readX(), writeX():
- 이것들은 메모리 공간보다는 I/O 공간에 이야기를 하려는 의도로
- 만들어졌습니다만, 그건 기본적으로 CPU 마다 다른 컨셉입니다. i386 과
- x86_64 프로세서들은 특별한 I/O 공간 액세스 사이클과 명령어를 실제로 가지고
- 있지만, 다른 많은 CPU 들에는 그런 컨셉이 존재하지 않습니다.
+ readX() 와 writeX() MMIO 액세스 함수는 접근되는 주변장치로의 포인터를
+ __iomem * 패러미터로 받습니다. 디폴트 I/O 기능으로 매핑되는 포인터 (예:
+ ioremap() 으로 반환되는 것) 의 순서 보장은 다음과 같습니다:
- 다른 것들 중에서도 PCI 버스가 I/O 공간 컨셉을 정의하는데, 이는 - i386 과
- x86_64 같은 CPU 에서 - CPU 의 I/O 공간 컨셉으로 쉽게 매치됩니다. 하지만,
- 대체할 I/O 공간이 없는 CPU 에서는 CPU 의 메모리 맵의 가상 I/O 공간으로
- 매핑될 수도 있습니다.
+ 1. 같은 주변장치로의 모든 readX() 와 writeX() 액세스는 각자에 대해
+ 순서지어집니다. 예를 들어, CPU 의 특정 디바이스로의 MMIO 레지스터
+ 쓰기는 프로그램 순서대로 도착할 것이 보장됩니다.
- 이 공간으로의 액세스는 (i386 등에서는) 완전하게 동기화 됩니다만, 중간의
- (PCI 호스트 브리지와 같은) 브리지들은 이를 완전히 보장하진 않을수도
- 있습니다.
+ 2. CPU 에 의한 특정 주변장치로의 writeX() 는 모든 앞선 CPU 의 메모리
+ 쓰기가 완료되기를 먼저 기다립니다. 예를 들어, dma_alloc_coherent() 를
+ 통해 할당된 전송용 DMA 버퍼로의 CPU 의 쓰기는 이 전송을 시작시키기 위해
+ CPU 가 MMIO 컨트롤 레지스터에 쓰기를 할 때 DMA 엔진에 보일 것이
+ 보장됩니다.
- 이것들의 상호간의 순서는 완전하게 보장됩니다.
+ 3. CPU 에 의한 주변장치로의 readX() 는 모든 뒤따르는 CPU 의 메모리
+ 읽기가 시작되기 전에 완료됩니다. 예를 들어, dma_alloc_coherent() 를
+ 통해 할당된 수신용 DMA 버퍼로부터의 CPU 의 읽기는 이 DMA 수신의 완료를
+ 표시하는 DMA 엔진의 MMIO 상태 레지스터 읽기 후에는 오염된 데이터를 읽지
+ 않을 것이 보장됩니다.
- 다른 타입의 메모리 오퍼레이션, I/O 오퍼레이션에 대한 순서는 완전하게
- 보장되지는 않습니다.
+ 4. CPU 에 의한 주변장치로의 readX() 는 모든 뒤따르는 delay() 루프가 수행을
+ 시작하기 전에 완료됩니다. 예를 들어, CPU 의 특정 주변장치로의 두개의
+ MMIO 레지스터 쓰기가 행해지는데 첫번째 쓰기가 readX() 를 통해 곧바로
+ 읽어졌고 이어 두번째 writeX() 전에 udelay(1) 이 호출되었다면 이 두개의
+ 쓰기는 최소 1us 의 간격을 두고 행해질 것이 보장됩니다.
- (*) readX(), writeX():
+ 디폴트가 아닌 기능을 통해 얻어지는 __iomem 포인터 (예: ioremap_wc() 를
+ 통해 리턴되는 것) 는 이런 보장사항들 중 다수를 제공하지 않을 수 있습니다.
+
+ (*) readX_relaxed(), writeX_relaxed()
+
+ 이것들은 readX() 와 writeX() 랑 비슷하지만, 더 완화된 메모리 순서 보장을
+ 제공합니다. 구체적으로, 이것들은 일반적 메모리 액세스나 delay() 루프
+ (예:앞의 2-4 항목) 에 대해 순서를 보장하지 않습니다만 디폴트 I/O 기능으로
+ 매핑된 __iomem 포인터에 대해 동작할 때 같은 주변장치로의 액세스에는 순서가
+ 맞춰질 것이 보장됩니다.
- 이것들이 수행 요청되는 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() 처럼 실제로 수행하는 액세스의
종류에 따라 적절하게 수행될 것입니다.
+이 모든 액세스 함수들은 아랫단의 주변장치가 little-endian 이라 가정하며, 따라서
+big-endian 아키텍쳐에서는 byte-swapping 오퍼레이션을 수행합니다.
+
+I/O 순서 배리어를 SMP 순서 배리어와 LOCK/UNLOCK 오퍼레이션과 섞는 건 mmiowb()
+를 필요로 할 수도 있는 위험한 행위입니다. 더 많은 내용을 위해선 "Acquire vs
+I/O 액세스" 서브섹션을 참고하시기 바랍니다.
+
===================================
가정되는 가장 완화된 실행 순서 모델
--
2.17.2
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH 2/7] Documentation/kokr: Kill all references to mmiowb()
2019-11-21 23:41 [PATCH 0/7] docs: Update ko_KR translations SeongJae Park
2019-11-21 23:41 ` [PATCH 1/7] docs/memory-barriers.txt/kokr: Rewrite "KERNEL I/O BARRIER EFFECTS" section SeongJae Park
@ 2019-11-21 23:41 ` SeongJae Park
2019-11-21 23:41 ` [PATCH 3/7] docs/memory-barriers.txt/kokr: Fix style, spacing and grammar in I/O section SeongJae Park
` (6 subsequent siblings)
8 siblings, 0 replies; 17+ messages in thread
From: SeongJae Park @ 2019-11-21 23:41 UTC (permalink / raw)
To: corbet, will, paulmck; +Cc: linux-kernel, linux-doc, SeongJae Park
Translate this commit to Korean:
915530396c78 ("Documentation: Kill all references to mmiowb()")
Signed-off-by: SeongJae Park <sj38.park@gmail.com>
---
.../translations/ko_KR/memory-barriers.txt | 104 +-----------------
1 file changed, 6 insertions(+), 98 deletions(-)
diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt
index 11fb7254ba8d..584bb0bdf2c4 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 메모리 윈도우로의 참조를 위해
+액세스 함수가 사용된다면 순서를 강제하기 위해 _madatory_ 메모리 배리어가
+필요합니다.
더 많은 정보를 위해선 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 에서 수행중이며 서로 통신을 하는 두 루틴
@@ -2641,10 +2553,6 @@ I/O 액세스를 통한 주변장치와의 통신은 아키텍쳐와 기기에
이 모든 액세스 함수들은 아랫단의 주변장치가 little-endian 이라 가정하며, 따라서
big-endian 아키텍쳐에서는 byte-swapping 오퍼레이션을 수행합니다.
-I/O 순서 배리어를 SMP 순서 배리어와 LOCK/UNLOCK 오퍼레이션과 섞는 건 mmiowb()
-를 필요로 할 수도 있는 위험한 행위입니다. 더 많은 내용을 위해선 "Acquire vs
-I/O 액세스" 서브섹션을 참고하시기 바랍니다.
-
===================================
가정되는 가장 완화된 실행 순서 모델
--
2.17.2
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH 3/7] docs/memory-barriers.txt/kokr: Fix style, spacing and grammar in I/O section
2019-11-21 23:41 [PATCH 0/7] docs: Update ko_KR translations SeongJae Park
2019-11-21 23:41 ` [PATCH 1/7] docs/memory-barriers.txt/kokr: Rewrite "KERNEL I/O BARRIER EFFECTS" section SeongJae Park
2019-11-21 23:41 ` [PATCH 2/7] Documentation/kokr: Kill all references to mmiowb() SeongJae Park
@ 2019-11-21 23:41 ` SeongJae Park
2019-11-21 23:41 ` [PATCH 4/7] docs/memory-barriers.txt/kokr: Update I/O section to be clearer about CPU vs thread SeongJae Park
` (5 subsequent siblings)
8 siblings, 0 replies; 17+ messages in thread
From: SeongJae Park @ 2019-11-21 23:41 UTC (permalink / raw)
To: corbet, will, paulmck; +Cc: linux-kernel, linux-doc, SeongJae Park
Translate this commit to Korean:
0cde62a46e88 ("docs/memory-barriers.txt: Fix style, spacing and grammar in I/O section")
Signed-off-by: SeongJae Park <sj38.park@gmail.com>
---
.../translations/ko_KR/memory-barriers.txt | 112 ++++++++++--------
1 file changed, 60 insertions(+), 52 deletions(-)
diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt
index 584bb0bdf2c4..1b9bfe54b3a5 100644
--- a/Documentation/translations/ko_KR/memory-barriers.txt
+++ b/Documentation/translations/ko_KR/memory-barriers.txt
@@ -2480,75 +2480,83 @@ I/O 액세스를 통한 주변장치와의 통신은 아키텍쳐와 기기에
(*) readX(), writeX():
- readX() 와 writeX() MMIO 액세스 함수는 접근되는 주변장치로의 포인터를
- __iomem * 패러미터로 받습니다. 디폴트 I/O 기능으로 매핑되는 포인터 (예:
- ioremap() 으로 반환되는 것) 의 순서 보장은 다음과 같습니다:
-
- 1. 같은 주변장치로의 모든 readX() 와 writeX() 액세스는 각자에 대해
- 순서지어집니다. 예를 들어, CPU 의 특정 디바이스로의 MMIO 레지스터
- 쓰기는 프로그램 순서대로 도착할 것이 보장됩니다.
-
- 2. CPU 에 의한 특정 주변장치로의 writeX() 는 모든 앞선 CPU 의 메모리
- 쓰기가 완료되기를 먼저 기다립니다. 예를 들어, dma_alloc_coherent() 를
- 통해 할당된 전송용 DMA 버퍼로의 CPU 의 쓰기는 이 전송을 시작시키기 위해
- CPU 가 MMIO 컨트롤 레지스터에 쓰기를 할 때 DMA 엔진에 보일 것이
- 보장됩니다.
-
- 3. CPU 에 의한 주변장치로의 readX() 는 모든 뒤따르는 CPU 의 메모리
- 읽기가 시작되기 전에 완료됩니다. 예를 들어, dma_alloc_coherent() 를
- 통해 할당된 수신용 DMA 버퍼로부터의 CPU 의 읽기는 이 DMA 수신의 완료를
- 표시하는 DMA 엔진의 MMIO 상태 레지스터 읽기 후에는 오염된 데이터를 읽지
- 않을 것이 보장됩니다.
-
- 4. CPU 에 의한 주변장치로의 readX() 는 모든 뒤따르는 delay() 루프가 수행을
- 시작하기 전에 완료됩니다. 예를 들어, CPU 의 특정 주변장치로의 두개의
- MMIO 레지스터 쓰기가 행해지는데 첫번째 쓰기가 readX() 를 통해 곧바로
- 읽어졌고 이어 두번째 writeX() 전에 udelay(1) 이 호출되었다면 이 두개의
- 쓰기는 최소 1us 의 간격을 두고 행해질 것이 보장됩니다.
-
- 디폴트가 아닌 기능을 통해 얻어지는 __iomem 포인터 (예: ioremap_wc() 를
- 통해 리턴되는 것) 는 이런 보장사항들 중 다수를 제공하지 않을 수 있습니다.
+ readX() 와 writeX() MMIO 액세스 함수는 접근되는 주변장치로의 포인터를
+ __iomem * 패러미터로 받습니다. 디폴트 I/O 기능으로 매핑되는 포인터
+ (예: ioremap() 으로 반환되는 것) 의 순서 보장은 다음과 같습니다:
+
+ 1. 같은 주변장치로의 모든 readX() 와 writeX() 액세스는 각자에 대해
+ 순서지어집니다. 예를 들어, CPU 의 특정 디바이스로의 MMIO 레지스터
+ 쓰기는 프로그램 순서대로 도착할 것이 보장됩니다.
+
+ 2. CPU 에 의한 특정 주변장치로의 writeX() 는 모든 앞선 CPU 의 메모리
+ 쓰기가 완료되기를 먼저 기다립니다. 예를 들어, dma_alloc_coherent()
+ 를 통해 할당된 전송용 DMA 버퍼로의 CPU 의 쓰기는 이 전송을
+ 시작시키기 위해 CPU 가 MMIO 컨트롤 레지스터에 쓰기를 할 때 DMA
+ 엔진에 보일 것이 보장됩니다.
+
+ 3. CPU 에 의한 주변장치로의 readX() 는 모든 뒤따르는 CPU 의 메모리
+ 읽기가 시작되기 전에 완료됩니다. 예를 들어, dma_alloc_coherent() 를
+ 통해 할당된 수신용 DMA 버퍼로부터의 CPU 의 읽기는 이 DMA 수신의
+ 완료를 표시하는 DMA 엔진의 MMIO 상태 레지스터 읽기 후에는 오염된
+ 데이터를 읽지 않을 것이 보장됩니다.
+
+ 4. 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() 를
+ 통해 리턴되는 것) 의 순서 속성은 실제 아키텍쳐에 의존적이어서 이런
+ 종류의 매핑으로의 액세스는 앞서 설명된 보장사항에 의존할 수 없습니다.
(*) readX_relaxed(), writeX_relaxed()
- 이것들은 readX() 와 writeX() 랑 비슷하지만, 더 완화된 메모리 순서 보장을
- 제공합니다. 구체적으로, 이것들은 일반적 메모리 액세스나 delay() 루프
- (예:앞의 2-4 항목) 에 대해 순서를 보장하지 않습니다만 디폴트 I/O 기능으로
- 매핑된 __iomem 포인터에 대해 동작할 때 같은 주변장치로의 액세스에는 순서가
- 맞춰질 것이 보장됩니다.
+ 이것들은 readX() 와 writeX() 랑 비슷하지만, 더 완화된 메모리 순서
+ 보장을 제공합니다. 구체적으로, 이것들은 일반적 메모리 액세스나 delay()
+ 루프 (예:앞의 2-4 항목) 에 대해 순서를 보장하지 않습니다만 디폴트 I/O
+ 기능으로 매핑된 __iomem 포인터에 대해 동작할 때 같은 주변장치로의
+ 액세스에는 순서가 맞춰질 것이 보장됩니다.
(*) readsX(), writesX():
- readsX() 와 writesX() MMIO 액세스 함수는 DMA 를 수행하는데 적절치 않은,
- 주변장치 내의 메모리 매핑된 레지스터 기반 FIFO 로의 액세스를 위해
- 설계되었습니다. 따라서, 이 기능들은 앞서 설명된 readX_relaxed() 와
- writeX_relaxed() 의 순서 보장만을 제공합니다.
+ readsX() 와 writesX() MMIO 액세스 함수는 DMA 를 수행하는데 적절치 않은,
+ 주변장치 내의 메모리 매핑된 레지스터 기반 FIFO 로의 액세스를 위해
+ 설계되었습니다. 따라서, 이 기능들은 앞서 설명된 readX_relaxed() 와
+ writeX_relaxed() 의 순서 보장만을 제공합니다.
(*) inX(), outX():
- inX() 와 outX() 액세스 함수는 일부 아키텍쳐 (특히 x86) 에서는 특수한
- 명령어를 필요로 하며 포트에 매핑되는, 과거의 유산인 I/O 주변장치로의
- 접근을 위해 만들어졌습니다.
+ inX() 와 outX() 액세스 함수는 일부 아키텍쳐 (특히 x86) 에서는 특수한
+ 명령어를 필요로 하며 포트에 매핑되는, 과거의 유산인 I/O 주변장치로의
+ 접근을 위해 만들어졌습니다.
- 많은 CPU 아키텍쳐가 결국은 이런 주변장치를 내부의 가상 메모리 매핑을 통해
- 접근하기 때문에, inX() 와 outX() 가 제공하는 이식성 있는 순서 보장은
- 디폴트 I/O 기능을 통한 매핑을 접근할 때의 readX() 와 writeX() 에 의해
- 제공되는 것과 각각 동일합니다.
+ 많은 CPU 아키텍쳐가 결국은 이런 주변장치를 내부의 가상 메모리 매핑을
+ 통해 접근하기 때문에, inX() 와 outX() 가 제공하는 이식성 있는 순서
+ 보장은 디폴트 I/O 기능을 통한 매핑을 접근할 때의 readX() 와 writeX() 에
+ 의해 제공되는 것과 각각 동일합니다.
- 디바이스 드라이버는 outX() 가 리턴하기 전에 해당 I/O 주변장치로부터의 완료
- 응답을 기다리는 쓰기 트랜잭션을 만들어 낸다고 기대할 수도 있습니다. 이는
- 모든 아키텍쳐에서 보장되지는 않고, 따라서 이식성 있는 순서 규칙의 일부분이
- 아닙니다.
+ 디바이스 드라이버는 outX() 가 리턴하기 전에 해당 I/O 주변장치로부터의
+ 완료 응답을 기다리는 쓰기 트랜잭션을 만들어 낸다고 기대할 수도
+ 있습니다. 이는 모든 아키텍쳐에서 보장되지는 않고, 따라서 이식성 있는
+ 순서 규칙의 일부분이 아닙니다.
(*) insX(), outsX():
- 앞에서와 같이, insX() 와 outsX() 액세스 함수는 디폴트 I/O 기능을 통한
- 매핑을 접근할 때 각각 readX() 와 writeX() 와 같은 순서 보장을 제공합니다.
+ 앞에서와 같이, insX() 와 outsX() 액세스 함수는 디폴트 I/O 기능을 통한
+ 매핑을 접근할 때 각각 readX() 와 writeX() 와 같은 순서 보장을
+ 제공합니다.
(*) ioreadX(), iowriteX()
- 이것들은 inX()/outX() 나 readX()/writeX() 처럼 실제로 수행하는 액세스의
- 종류에 따라 적절하게 수행될 것입니다.
+ 이것들은 inX()/outX() 나 readX()/writeX() 처럼 실제로 수행하는 액세스의
+ 종류에 따라 적절하게 수행될 것입니다.
이 모든 액세스 함수들은 아랫단의 주변장치가 little-endian 이라 가정하며, 따라서
big-endian 아키텍쳐에서는 byte-swapping 오퍼레이션을 수행합니다.
--
2.17.2
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH 4/7] docs/memory-barriers.txt/kokr: Update I/O section to be clearer about CPU vs thread
2019-11-21 23:41 [PATCH 0/7] docs: Update ko_KR translations SeongJae Park
` (2 preceding siblings ...)
2019-11-21 23:41 ` [PATCH 3/7] docs/memory-barriers.txt/kokr: Fix style, spacing and grammar in I/O section SeongJae Park
@ 2019-11-21 23:41 ` SeongJae Park
2019-11-21 23:41 ` [PATCH 5/7] docs/memory-barriers.txt: Remove remaining references to mmiowb() SeongJae Park
` (4 subsequent siblings)
8 siblings, 0 replies; 17+ messages in thread
From: SeongJae Park @ 2019-11-21 23:41 UTC (permalink / raw)
To: corbet, will, paulmck; +Cc: linux-kernel, linux-doc, SeongJae Park
Translate this commit to Korean:
9726840d9cf0 ("docs/memory-barriers.txt: Update I/O section to be clearer about CPU vs thread")
Signed-off-by: SeongJae Park <sj38.park@gmail.com>
---
.../translations/ko_KR/memory-barriers.txt | 56 +++++++++++--------
1 file changed, 32 insertions(+), 24 deletions(-)
diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt
index 1b9bfe54b3a5..a8d26df9360b 100644
--- a/Documentation/translations/ko_KR/memory-barriers.txt
+++ b/Documentation/translations/ko_KR/memory-barriers.txt
@@ -2485,27 +2485,34 @@ I/O 액세스를 통한 주변장치와의 통신은 아키텍쳐와 기기에
(예: ioremap() 으로 반환되는 것) 의 순서 보장은 다음과 같습니다:
1. 같은 주변장치로의 모든 readX() 와 writeX() 액세스는 각자에 대해
- 순서지어집니다. 예를 들어, CPU 의 특정 디바이스로의 MMIO 레지스터
- 쓰기는 프로그램 순서대로 도착할 것이 보장됩니다.
-
- 2. CPU 에 의한 특정 주변장치로의 writeX() 는 모든 앞선 CPU 의 메모리
- 쓰기가 완료되기를 먼저 기다립니다. 예를 들어, dma_alloc_coherent()
- 를 통해 할당된 전송용 DMA 버퍼로의 CPU 의 쓰기는 이 전송을
- 시작시키기 위해 CPU 가 MMIO 컨트롤 레지스터에 쓰기를 할 때 DMA
- 엔진에 보일 것이 보장됩니다.
-
- 3. CPU 에 의한 주변장치로의 readX() 는 모든 뒤따르는 CPU 의 메모리
- 읽기가 시작되기 전에 완료됩니다. 예를 들어, dma_alloc_coherent() 를
- 통해 할당된 수신용 DMA 버퍼로부터의 CPU 의 읽기는 이 DMA 수신의
- 완료를 표시하는 DMA 엔진의 MMIO 상태 레지스터 읽기 후에는 오염된
- 데이터를 읽지 않을 것이 보장됩니다.
-
- 4. CPU 에 의한 주변장치로의 readX() 는 모든 뒤따르는 delay() 루프가
- 수행을 시작하기 전에 완료됩니다. 예를 들어, CPU 의 특정
+ 순서지어집니다. 이는 같은 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 의 간격을 두고 행해질 것이
- 보장됩니다:
+ 이 호출되었다면 이 두개의 쓰기는 최소 1us 의 간격을 두고 행해질 것을
+ 보장합니다:
writel(42, DEVICE_REGISTER_0); // 디바이스에 도착함...
readl(DEVICE_REGISTER_0);
@@ -2520,9 +2527,9 @@ I/O 액세스를 통한 주변장치와의 통신은 아키텍쳐와 기기에
이것들은 readX() 와 writeX() 랑 비슷하지만, 더 완화된 메모리 순서
보장을 제공합니다. 구체적으로, 이것들은 일반적 메모리 액세스나 delay()
- 루프 (예:앞의 2-4 항목) 에 대해 순서를 보장하지 않습니다만 디폴트 I/O
- 기능으로 매핑된 __iomem 포인터에 대해 동작할 때 같은 주변장치로의
- 액세스에는 순서가 맞춰질 것이 보장됩니다.
+ 루프 (예:앞의 2-5 항목) 에 대해 순서를 보장하지 않습니다만 디폴트 I/O
+ 기능으로 매핑된 __iomem 포인터에 대해 동작할 때, 같은 CPU 쓰레드에 의해
+ 같은 주변장치로의 액세스에는 순서가 맞춰질 것이 보장됩니다.
(*) readsX(), writesX():
@@ -2558,8 +2565,9 @@ I/O 액세스를 통한 주변장치와의 통신은 아키텍쳐와 기기에
이것들은 inX()/outX() 나 readX()/writeX() 처럼 실제로 수행하는 액세스의
종류에 따라 적절하게 수행될 것입니다.
-이 모든 액세스 함수들은 아랫단의 주변장치가 little-endian 이라 가정하며, 따라서
-big-endian 아키텍쳐에서는 byte-swapping 오퍼레이션을 수행합니다.
+String 액세스 함수 (insX(), outsX(), readsX() 그리고 writesX()) 의 예외를
+제외하고는, 앞의 모든 것이 아랫단의 주변장치가 little-endian 이라 가정하며,
+따라서 big-endian 아키텍쳐에서는 byte-swapping 오퍼레이션을 수행합니다.
===================================
--
2.17.2
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH 5/7] docs/memory-barriers.txt: Remove remaining references to mmiowb()
2019-11-21 23:41 [PATCH 0/7] docs: Update ko_KR translations SeongJae Park
` (3 preceding siblings ...)
2019-11-21 23:41 ` [PATCH 4/7] docs/memory-barriers.txt/kokr: Update I/O section to be clearer about CPU vs thread SeongJae Park
@ 2019-11-21 23:41 ` SeongJae Park
2019-11-21 23:41 ` [PATCH 6/7] Documentation/translation: Use Korean for Korean translation title SeongJae Park
` (3 subsequent siblings)
8 siblings, 0 replies; 17+ messages in thread
From: SeongJae Park @ 2019-11-21 23:41 UTC (permalink / raw)
To: corbet, will, paulmck; +Cc: linux-kernel, linux-doc, SeongJae Park
This commit removes references to sections erased by Commit 915530396c78
("Documentation: Kill all references to mmiowb()").
Signed-off-by: SeongJae Park <sj38.park@gmail.com>
---
Documentation/memory-barriers.txt | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index 1adbb8a371c7..ec3b5865c1be 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -63,7 +63,6 @@ CONTENTS
- Compiler barrier.
- CPU memory barriers.
- - MMIO write barrier.
(*) Implicit kernel memory barriers.
@@ -75,7 +74,6 @@ CONTENTS
(*) Inter-CPU acquiring barrier effects.
- Acquires vs memory accesses.
- - Acquires vs I/O accesses.
(*) Where are memory barriers needed?
@@ -492,10 +490,9 @@ And a couple of implicit varieties:
happen before it completes.
The use of ACQUIRE and RELEASE operations generally precludes the need
- for other sorts of memory barrier (but note the exceptions mentioned in
- the subsection "MMIO write barrier"). In addition, a RELEASE+ACQUIRE
- pair is -not- guaranteed to act as a full memory barrier. However, after
- an ACQUIRE on a given variable, all memory accesses preceding any prior
+ for other sorts of memory barrier. In addition, a RELEASE+ACQUIRE pair is
+ -not- guaranteed to act as a full memory barrier. However, after an
+ ACQUIRE on a given variable, all memory accesses preceding any prior
RELEASE on that same variable are guaranteed to be visible. In other
words, within a given variable's critical section, all accesses of all
previous critical sections for that variable are guaranteed to have
@@ -1512,8 +1509,6 @@ levels:
(*) CPU memory barriers.
- (*) MMIO write barrier.
-
COMPILER BARRIER
----------------
--
2.17.2
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH 6/7] Documentation/translation: Use Korean for Korean translation title
2019-11-21 23:41 [PATCH 0/7] docs: Update ko_KR translations SeongJae Park
` (4 preceding siblings ...)
2019-11-21 23:41 ` [PATCH 5/7] docs/memory-barriers.txt: Remove remaining references to mmiowb() SeongJae Park
@ 2019-11-21 23:41 ` SeongJae Park
2019-11-21 23:41 ` [PATCH 7/7] Documentation/process/howto/kokr: Update for 4.x -> 5.x versioning SeongJae Park
` (2 subsequent siblings)
8 siblings, 0 replies; 17+ messages in thread
From: SeongJae Park @ 2019-11-21 23:41 UTC (permalink / raw)
To: corbet, will, paulmck; +Cc: linux-kernel, linux-doc, SeongJae Park
Signed-off-by: SeongJae Park <sj38.park@gmail.com>
---
Documentation/translations/ko_KR/index.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
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
--
2.17.2
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH 7/7] Documentation/process/howto/kokr: Update for 4.x -> 5.x versioning
2019-11-21 23:41 [PATCH 0/7] docs: Update ko_KR translations SeongJae Park
` (5 preceding siblings ...)
2019-11-21 23:41 ` [PATCH 6/7] Documentation/translation: Use Korean for Korean translation title SeongJae Park
@ 2019-11-21 23:41 ` SeongJae Park
2019-11-22 17:01 ` [PATCH 0/7] docs: Update ko_KR translations Jonathan Corbet
2019-11-26 22:21 ` Paul E. McKenney
8 siblings, 0 replies; 17+ messages in thread
From: SeongJae Park @ 2019-11-21 23:41 UTC (permalink / raw)
To: corbet, will, paulmck; +Cc: linux-kernel, linux-doc, SeongJae Park
Translate this commit to Korean:
d2b008f134b7 ("Documentation/process/howto: Update for 4.x -> 5.x versioning")
Signed-off-by: SeongJae Park <sj38.park@gmail.com>
---
Documentation/translations/ko_KR/howto.rst | 56 +++++++++++-----------
1 file changed, 27 insertions(+), 29 deletions(-)
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
+커널에서 테스트를 수행하는 것도 좋을 것이다.
버그 보고
--
2.17.2
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH 0/7] docs: Update ko_KR translations
2019-11-21 23:41 [PATCH 0/7] docs: Update ko_KR translations SeongJae Park
` (6 preceding siblings ...)
2019-11-21 23:41 ` [PATCH 7/7] Documentation/process/howto/kokr: Update for 4.x -> 5.x versioning SeongJae Park
@ 2019-11-22 17:01 ` Jonathan Corbet
2019-11-26 22:21 ` Paul E. McKenney
8 siblings, 0 replies; 17+ messages in thread
From: Jonathan Corbet @ 2019-11-22 17:01 UTC (permalink / raw)
To: SeongJae Park; +Cc: will, paulmck, linux-kernel, linux-doc
On Fri, 22 Nov 2019 00:41:18 +0100
SeongJae Park <sj38.park@gmail.com> wrote:
> This patchset contains updates of Korean translation documents and a fix
> of original document.
>
> First 4 patches update the Korean translation of memory-barriers.txt.
> Fifth patch fixes a broken section reference in the original
> memory-barriers.txt.
>
> Sixth and seventh patches update the Korean translation of howto.rst.
I've applied the set, thanks.
jon
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 0/7] docs: Update ko_KR translations
2019-11-21 23:41 [PATCH 0/7] docs: Update ko_KR translations SeongJae Park
` (7 preceding siblings ...)
2019-11-22 17:01 ` [PATCH 0/7] docs: Update ko_KR translations Jonathan Corbet
@ 2019-11-26 22:21 ` Paul E. McKenney
2019-11-26 22:36 ` SeongJae Park
2019-11-27 14:12 ` Jonathan Corbet
8 siblings, 2 replies; 17+ messages in thread
From: Paul E. McKenney @ 2019-11-26 22:21 UTC (permalink / raw)
To: SeongJae Park; +Cc: corbet, will, linux-kernel, linux-doc
On Fri, Nov 22, 2019 at 12:41:18AM +0100, SeongJae Park wrote:
> This patchset contains updates of Korean translation documents and a fix
> of original document.
>
> First 4 patches update the Korean translation of memory-barriers.txt.
> Fifth patch fixes a broken section reference in the original
> memory-barriers.txt.
>
> Sixth and seventh patches update the Korean translation of howto.rst.
The sixth and seventh probably have some other more natural path,
but I queued them. Any chance of a Reviewed-by from one of our other
Korean-language kernel hackers?
Thanx, Paul
> *** BLURB HERE ***
>
> SeongJae Park (7):
> docs/memory-barriers.txt/kokr: Rewrite "KERNEL I/O BARRIER EFFECTS"
> section
> Documentation/kokr: Kill all references to mmiowb()
> docs/memory-barriers.txt/kokr: Fix style, spacing and grammar in I/O
> section
> docs/memory-barriers.txt/kokr: Update I/O section to be clearer about
> CPU vs thread
> docs/memory-barriers.txt: Remove remaining references to mmiowb()
> Documentation/translation: Use Korean for Korean translation title
> Documentation/process/howto/kokr: Update for 4.x -> 5.x versioning
>
> Documentation/memory-barriers.txt | 11 +-
> Documentation/translations/ko_KR/howto.rst | 56 +++--
> Documentation/translations/ko_KR/index.rst | 4 +-
> .../translations/ko_KR/memory-barriers.txt | 227 +++++++-----------
> 4 files changed, 119 insertions(+), 179 deletions(-)
>
> --
> 2.17.2
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 0/7] docs: Update ko_KR translations
2019-11-26 22:21 ` Paul E. McKenney
@ 2019-11-26 22:36 ` SeongJae Park
2019-11-27 14:12 ` Jonathan Corbet
1 sibling, 0 replies; 17+ messages in thread
From: SeongJae Park @ 2019-11-26 22:36 UTC (permalink / raw)
To: Paul E. McKenney; +Cc: Jonathan Corbet, Will Deacon, LKML, linux-doc
On Tue, Nov 26, 2019 at 11:21 PM Paul E. McKenney <paulmck@kernel.org> wrote:
>
> On Fri, Nov 22, 2019 at 12:41:18AM +0100, SeongJae Park wrote:
> > This patchset contains updates of Korean translation documents and a fix
> > of original document.
> >
> > First 4 patches update the Korean translation of memory-barriers.txt.
> > Fifth patch fixes a broken section reference in the original
> > memory-barriers.txt.
> >
> > Sixth and seventh patches update the Korean translation of howto.rst.
>
> The sixth and seventh probably have some other more natural path,
> but I queued them. Any chance of a Reviewed-by from one of our other
> Korean-language kernel hackers?
Thanks, Paul. I asked a review to my Korean ex-colleague. Will update the
results, soon!
Thanks,
SeongJae Park
>
> Thanx, Paul
>
> > *** BLURB HERE ***
> >
> > SeongJae Park (7):
> > docs/memory-barriers.txt/kokr: Rewrite "KERNEL I/O BARRIER EFFECTS"
> > section
> > Documentation/kokr: Kill all references to mmiowb()
> > docs/memory-barriers.txt/kokr: Fix style, spacing and grammar in I/O
> > section
> > docs/memory-barriers.txt/kokr: Update I/O section to be clearer about
> > CPU vs thread
> > docs/memory-barriers.txt: Remove remaining references to mmiowb()
> > Documentation/translation: Use Korean for Korean translation title
> > Documentation/process/howto/kokr: Update for 4.x -> 5.x versioning
> >
> > Documentation/memory-barriers.txt | 11 +-
> > Documentation/translations/ko_KR/howto.rst | 56 +++--
> > Documentation/translations/ko_KR/index.rst | 4 +-
> > .../translations/ko_KR/memory-barriers.txt | 227 +++++++-----------
> > 4 files changed, 119 insertions(+), 179 deletions(-)
> >
> > --
> > 2.17.2
> >
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 0/7] docs: Update ko_KR translations
2019-11-26 22:21 ` Paul E. McKenney
2019-11-26 22:36 ` SeongJae Park
@ 2019-11-27 14:12 ` Jonathan Corbet
2019-11-27 14:27 ` Paul E. McKenney
1 sibling, 1 reply; 17+ messages in thread
From: Jonathan Corbet @ 2019-11-27 14:12 UTC (permalink / raw)
To: Paul E. McKenney; +Cc: SeongJae Park, will, linux-kernel, linux-doc
On Tue, 26 Nov 2019 14:21:44 -0800
"Paul E. McKenney" <paulmck@kernel.org> wrote:
> On Fri, Nov 22, 2019 at 12:41:18AM +0100, SeongJae Park wrote:
> > This patchset contains updates of Korean translation documents and a fix
> > of original document.
> >
> > First 4 patches update the Korean translation of memory-barriers.txt.
> > Fifth patch fixes a broken section reference in the original
> > memory-barriers.txt.
> >
> > Sixth and seventh patches update the Korean translation of howto.rst.
>
> The sixth and seventh probably have some other more natural path,
> but I queued them. Any chance of a Reviewed-by from one of our other
> Korean-language kernel hackers?
I applied the whole set to docs-next a few days ago...apologies if that's
not the way you wanted these handled.
jon
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 0/7] docs: Update ko_KR translations
2019-11-27 14:12 ` Jonathan Corbet
@ 2019-11-27 14:27 ` Paul E. McKenney
2019-11-29 18:28 ` [PATCH] docs/memory-barriers.txt.kokr: Minor wordsmith SeongJae Park
0 siblings, 1 reply; 17+ messages in thread
From: Paul E. McKenney @ 2019-11-27 14:27 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: SeongJae Park, will, linux-kernel, linux-doc
On Wed, Nov 27, 2019 at 07:12:05AM -0700, Jonathan Corbet wrote:
> On Tue, 26 Nov 2019 14:21:44 -0800
> "Paul E. McKenney" <paulmck@kernel.org> wrote:
>
> > On Fri, Nov 22, 2019 at 12:41:18AM +0100, SeongJae Park wrote:
> > > This patchset contains updates of Korean translation documents and a fix
> > > of original document.
> > >
> > > First 4 patches update the Korean translation of memory-barriers.txt.
> > > Fifth patch fixes a broken section reference in the original
> > > memory-barriers.txt.
> > >
> > > Sixth and seventh patches update the Korean translation of howto.rst.
> >
> > The sixth and seventh probably have some other more natural path,
> > but I queued them. Any chance of a Reviewed-by from one of our other
> > Korean-language kernel hackers?
>
> I applied the whole set to docs-next a few days ago...apologies if that's
> not the way you wanted these handled.
Even better! I will drop them from -rcu.
Thanx, Paul
^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH] docs/memory-barriers.txt.kokr: Minor wordsmith
2019-11-27 14:27 ` Paul E. McKenney
@ 2019-11-29 18:28 ` SeongJae Park
2019-12-06 17:21 ` SeongJae Park
2019-12-19 16:41 ` Jonathan Corbet
0 siblings, 2 replies; 17+ messages in thread
From: SeongJae Park @ 2019-11-29 18:28 UTC (permalink / raw)
To: corbet, paulmck; +Cc: will, linux-kernel, linux-doc, SeongJae Park
As suggested by Paul, I got a review from another Korean hacker Yunjae.
From the review, I got not only 'Reviewed-by:' tags, but also found a
few minor nits. So I made a second version of the patchset but just
realized that the first version has already sent to Linus. I therefore
send only the nit fixes as another patch.
----------------------------- >8 ----------------------------------------
docs/memory-barriers.txt.kokr: Minor wordsmith
This commit fixes a couple of minor nits in the Korean translation of
'memory-barriers.txt'.
Signed-off-by: SeongJae Park <sjpark@amazon.de>
Reviewed-by: Yunjae Lee <lyj7694@gmail.com>
---
Documentation/translations/ko_KR/memory-barriers.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt
index a8d26df9360b..29e76a73ae59 100644
--- a/Documentation/translations/ko_KR/memory-barriers.txt
+++ b/Documentation/translations/ko_KR/memory-barriers.txt
@@ -2413,7 +2413,7 @@ _않습니다_.
알고 있는, - inb() 나 writel() 과 같은 - 적절한 액세스 루틴을 통해 이루어져야만
합니다. 이것들은 대부분의 경우에는 명시적 메모리 배리어 와 함께 사용될 필요가
없습니다만, 완화된 메모리 액세스 속성으로 I/O 메모리 윈도우로의 참조를 위해
-액세스 함수가 사용된다면 순서를 강제하기 위해 _madatory_ 메모리 배리어가
+액세스 함수가 사용된다면 순서를 강제하기 위해 _mandatory_ 메모리 배리어가
필요합니다.
더 많은 정보를 위해선 Documentation/driver-api/device-io.rst 를 참고하십시오.
@@ -2528,7 +2528,7 @@ I/O 액세스를 통한 주변장치와의 통신은 아키텍쳐와 기기에
이것들은 readX() 와 writeX() 랑 비슷하지만, 더 완화된 메모리 순서
보장을 제공합니다. 구체적으로, 이것들은 일반적 메모리 액세스나 delay()
루프 (예:앞의 2-5 항목) 에 대해 순서를 보장하지 않습니다만 디폴트 I/O
- 기능으로 매핑된 __iomem 포인터에 대해 동작할 때, 같은 CPU 쓰레드에 의해
+ 기능으로 매핑된 __iomem 포인터에 대해 동작할 때, 같은 CPU 쓰레드에 의한
같은 주변장치로의 액세스에는 순서가 맞춰질 것이 보장됩니다.
(*) readsX(), writesX():
--
2.17.2
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH] docs/memory-barriers.txt.kokr: Minor wordsmith
2019-11-29 18:28 ` [PATCH] docs/memory-barriers.txt.kokr: Minor wordsmith SeongJae Park
@ 2019-12-06 17:21 ` SeongJae Park
2019-12-12 17:30 ` SeongJae Park
2019-12-19 16:41 ` Jonathan Corbet
1 sibling, 1 reply; 17+ messages in thread
From: SeongJae Park @ 2019-12-06 17:21 UTC (permalink / raw)
To: Jonathan Corbet, Paul E. McKenney
Cc: Will Deacon, LKML, linux-doc, SeongJae Park
Hello Jon and Paul,
On Fri, Nov 29, 2019 at 7:29 PM SeongJae Park <sj38.park@gmail.com> wrote:
>
> As suggested by Paul, I got a review from another Korean hacker Yunjae.
> From the review, I got not only 'Reviewed-by:' tags, but also found a
> few minor nits. So I made a second version of the patchset but just
> realized that the first version has already sent to Linus. I therefore
> send only the nit fixes as another patch.
May I ask your comments?
Thanks,
SeongJae Park
>
> ----------------------------- >8 ----------------------------------------
> docs/memory-barriers.txt.kokr: Minor wordsmith
>
> This commit fixes a couple of minor nits in the Korean translation of
> 'memory-barriers.txt'.
>
> Signed-off-by: SeongJae Park <sjpark@amazon.de>
> Reviewed-by: Yunjae Lee <lyj7694@gmail.com>
> ---
> Documentation/translations/ko_KR/memory-barriers.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt
> index a8d26df9360b..29e76a73ae59 100644
> --- a/Documentation/translations/ko_KR/memory-barriers.txt
> +++ b/Documentation/translations/ko_KR/memory-barriers.txt
> @@ -2413,7 +2413,7 @@ _않습니다_.
> 알고 있는, - inb() 나 writel() 과 같은 - 적절한 액세스 루틴을 통해 이루어져야만
> 합니다. 이것들은 대부분의 경우에는 명시적 메모리 배리어 와 함께 사용될 필요가
> 없습니다만, 완화된 메모리 액세스 속성으로 I/O 메모리 윈도우로의 참조를 위해
> -액세스 함수가 사용된다면 순서를 강제하기 위해 _madatory_ 메모리 배리어가
> +액세스 함수가 사용된다면 순서를 강제하기 위해 _mandatory_ 메모리 배리어가
> 필요합니다.
>
> 더 많은 정보를 위해선 Documentation/driver-api/device-io.rst 를 참고하십시오.
> @@ -2528,7 +2528,7 @@ I/O 액세스를 통한 주변장치와의 통신은 아키텍쳐와 기기에
> 이것들은 readX() 와 writeX() 랑 비슷하지만, 더 완화된 메모리 순서
> 보장을 제공합니다. 구체적으로, 이것들은 일반적 메모리 액세스나 delay()
> 루프 (예:앞의 2-5 항목) 에 대해 순서를 보장하지 않습니다만 디폴트 I/O
> - 기능으로 매핑된 __iomem 포인터에 대해 동작할 때, 같은 CPU 쓰레드에 의해
> + 기능으로 매핑된 __iomem 포인터에 대해 동작할 때, 같은 CPU 쓰레드에 의한
> 같은 주변장치로의 액세스에는 순서가 맞춰질 것이 보장됩니다.
>
> (*) readsX(), writesX():
> --
> 2.17.2
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] docs/memory-barriers.txt.kokr: Minor wordsmith
2019-12-06 17:21 ` SeongJae Park
@ 2019-12-12 17:30 ` SeongJae Park
0 siblings, 0 replies; 17+ messages in thread
From: SeongJae Park @ 2019-12-12 17:30 UTC (permalink / raw)
To: Jonathan Corbet, Paul E. McKenney
Cc: Will Deacon, LKML, linux-doc, SeongJae Park
Hello Jon,
On Fri, Dec 6, 2019 at 6:21 PM SeongJae Park <sj38.park@gmail.com> wrote:
>
> Hello Jon and Paul,
>
> On Fri, Nov 29, 2019 at 7:29 PM SeongJae Park <sj38.park@gmail.com> wrote:
> >
> > As suggested by Paul, I got a review from another Korean hacker Yunjae.
> > From the review, I got not only 'Reviewed-by:' tags, but also found a
> > few minor nits. So I made a second version of the patchset but just
> > realized that the first version has already sent to Linus. I therefore
> > send only the nit fixes as another patch.
>
> May I ask your comments?
May I ask your comments?
Thanks,
SeongJae Park
>
>
> Thanks,
> SeongJae Park
>
> >
> > ----------------------------- >8 ----------------------------------------
> > docs/memory-barriers.txt.kokr: Minor wordsmith
> >
> > This commit fixes a couple of minor nits in the Korean translation of
> > 'memory-barriers.txt'.
> >
> > Signed-off-by: SeongJae Park <sjpark@amazon.de>
> > Reviewed-by: Yunjae Lee <lyj7694@gmail.com>
> > ---
> > Documentation/translations/ko_KR/memory-barriers.txt | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt
> > index a8d26df9360b..29e76a73ae59 100644
> > --- a/Documentation/translations/ko_KR/memory-barriers.txt
> > +++ b/Documentation/translations/ko_KR/memory-barriers.txt
> > @@ -2413,7 +2413,7 @@ _않습니다_.
> > 알고 있는, - inb() 나 writel() 과 같은 - 적절한 액세스 루틴을 통해 이루어져야만
> > 합니다. 이것들은 대부분의 경우에는 명시적 메모리 배리어 와 함께 사용될 필요가
> > 없습니다만, 완화된 메모리 액세스 속성으로 I/O 메모리 윈도우로의 참조를 위해
> > -액세스 함수가 사용된다면 순서를 강제하기 위해 _madatory_ 메모리 배리어가
> > +액세스 함수가 사용된다면 순서를 강제하기 위해 _mandatory_ 메모리 배리어가
> > 필요합니다.
> >
> > 더 많은 정보를 위해선 Documentation/driver-api/device-io.rst 를 참고하십시오.
> > @@ -2528,7 +2528,7 @@ I/O 액세스를 통한 주변장치와의 통신은 아키텍쳐와 기기에
> > 이것들은 readX() 와 writeX() 랑 비슷하지만, 더 완화된 메모리 순서
> > 보장을 제공합니다. 구체적으로, 이것들은 일반적 메모리 액세스나 delay()
> > 루프 (예:앞의 2-5 항목) 에 대해 순서를 보장하지 않습니다만 디폴트 I/O
> > - 기능으로 매핑된 __iomem 포인터에 대해 동작할 때, 같은 CPU 쓰레드에 의해
> > + 기능으로 매핑된 __iomem 포인터에 대해 동작할 때, 같은 CPU 쓰레드에 의한
> > 같은 주변장치로의 액세스에는 순서가 맞춰질 것이 보장됩니다.
> >
> > (*) readsX(), writesX():
> > --
> > 2.17.2
> >
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH] docs/memory-barriers.txt.kokr: Minor wordsmith
2019-11-29 18:28 ` [PATCH] docs/memory-barriers.txt.kokr: Minor wordsmith SeongJae Park
2019-12-06 17:21 ` SeongJae Park
@ 2019-12-19 16:41 ` Jonathan Corbet
1 sibling, 0 replies; 17+ messages in thread
From: Jonathan Corbet @ 2019-12-19 16:41 UTC (permalink / raw)
To: SeongJae Park; +Cc: paulmck, will, linux-kernel, linux-doc, SeongJae Park
On Fri, 29 Nov 2019 19:28:23 +0100
SeongJae Park <sj38.park@gmail.com> wrote:
> As suggested by Paul, I got a review from another Korean hacker Yunjae.
> From the review, I got not only 'Reviewed-by:' tags, but also found a
> few minor nits. So I made a second version of the patchset but just
> realized that the first version has already sent to Linus. I therefore
> send only the nit fixes as another patch.
>
> ----------------------------- >8 ----------------------------------------
> docs/memory-barriers.txt.kokr: Minor wordsmith
>
> This commit fixes a couple of minor nits in the Korean translation of
> 'memory-barriers.txt'.
>
> Signed-off-by: SeongJae Park <sjpark@amazon.de>
> Reviewed-by: Yunjae Lee <lyj7694@gmail.com>
> ---
> Documentation/translations/ko_KR/memory-barriers.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
I've applied this; thanks and apologies for the delay,
jon
^ permalink raw reply [flat|nested] 17+ messages in thread