diff options
Diffstat (limited to 'Documentation/translations')
21 files changed, 477 insertions, 187 deletions
diff --git a/Documentation/translations/it_IT/core-api/index.rst b/Documentation/translations/it_IT/core-api/index.rst new file mode 100644 index 000000000000..cc4c4328ad03 --- /dev/null +++ b/Documentation/translations/it_IT/core-api/index.rst @@ -0,0 +1,18 @@ +=============================== +Documentazione dell'API di base +=============================== + +Utilità di base +=============== + +.. toctree:: + :maxdepth: 1 + + symbol-namespaces + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/translations/it_IT/core-api/symbol-namespaces.rst b/Documentation/translations/it_IT/core-api/symbol-namespaces.rst new file mode 100644 index 000000000000..aa851a57a4b0 --- /dev/null +++ b/Documentation/translations/it_IT/core-api/symbol-namespaces.rst @@ -0,0 +1,166 @@ +.. include:: ../disclaimer-ita.rst + +:Original: :doc:`../../../core-api/symbol-namespaces` +:Translator: Federico Vaga <federico.vaga@vaga.pv.it> + +=========================== +Spazio dei nomi dei simboli +=========================== + +Questo documento descrive come usare lo spazio dei nomi dei simboli +per strutturare quello che viene esportato internamente al kernel +grazie alle macro della famiglia EXPORT_SYMBOL(). + +1. Introduzione +=============== + +Lo spazio dei nomi dei simboli è stato introdotto come mezzo per strutturare +l'API esposta internamente al kernel. Permette ai manutentori di un +sottosistema di organizzare i simboli esportati in diversi spazi di +nomi. Questo meccanismo è utile per la documentazione (pensate ad +esempio allo spazio dei nomi SUBSYSTEM_DEBUG) così come per limitare +la disponibilità di un gruppo di simboli in altre parti del kernel. Ad +oggi, i moduli che usano simboli esportati da uno spazio di nomi +devono prima importare detto spazio. Altrimenti il kernel, a seconda +della configurazione, potrebbe rifiutare di caricare il modulo o +avvisare l'utente di un'importazione mancante. + +2. Come definire uno spazio dei nomi dei simboli +================================================ + +I simboli possono essere esportati in spazi dei nomi usando diversi +meccanismi. Tutti questi meccanismi cambiano il modo in cui +EXPORT_SYMBOL e simili vengono guidati verso la creazione di voci in ksymtab. + +2.1 Usare le macro EXPORT_SYMBOL +================================ + +In aggiunta alle macro EXPORT_SYMBOL() e EXPORT_SYMBOL_GPL(), che permettono +di esportare simboli del kernel nella rispettiva tabella, ci sono +varianti che permettono di esportare simboli all'interno di uno spazio dei +nomi: EXPORT_SYMBOL_NS() ed EXPORT_SYMBOL_NS_GPL(). Queste macro richiedono un +argomento aggiuntivo: lo spazio dei nomi. +Tenete presente che per via dell'espansione delle macro questo argomento deve +essere un simbolo di preprocessore. Per esempio per esportare il +simbolo `usb_stor_suspend` nello spazio dei nomi `USB_STORAGE` usate:: + + EXPORT_SYMBOL_NS(usb_stor_suspend, USB_STORAGE); + +Di conseguenza, nella tabella dei simboli del kernel ci sarà una voce +rappresentata dalla struttura `kernel_symbol` che avrà il campo +`namespace` (spazio dei nomi) impostato. Un simbolo esportato senza uno spazio +dei nomi avrà questo campo impostato a `NULL`. Non esiste uno spazio dei nomi +di base. Il programma `modpost` e il codice in kernel/module.c usano lo spazio +dei nomi, rispettivamente, durante la compilazione e durante il caricamento +di un modulo. + +2.2 Usare il simbolo di preprocessore DEFAULT_SYMBOL_NAMESPACE +============================================================== + +Definire lo spazio dei nomi per tutti i simboli di un sottosistema può essere +logorante e di difficile manutenzione. Perciò è stato fornito un simbolo +di preprocessore di base (DEFAULT_SYMBOL_NAMESPACE), che, se impostato, +diventa lo spazio dei simboli di base per tutti gli usi di EXPORT_SYMBOL() +ed EXPORT_SYMBOL_GPL() che non specificano esplicitamente uno spazio dei nomi. + +Ci sono molti modi per specificare questo simbolo di preprocessore e il loro +uso dipende dalle preferenze del manutentore di un sottosistema. La prima +possibilità è quella di definire il simbolo nel `Makefile` del sottosistema. +Per esempio per esportare tutti i simboli definiti in usb-common nello spazio +dei nomi USB_COMMON, si può aggiungere la seguente linea in +drivers/usb/common/Makefile:: + + ccflags-y += -DDEFAULT_SYMBOL_NAMESPACE=USB_COMMON + +Questo cambierà tutte le macro EXPORT_SYMBOL() ed EXPORT_SYMBOL_GPL(). Invece, +un simbolo esportato con EXPORT_SYMBOL_NS() non verrà cambiato e il simbolo +verrà esportato nello spazio dei nomi indicato. + +Una seconda possibilità è quella di definire il simbolo di preprocessore +direttamente nei file da compilare. L'esempio precedente diventerebbe:: + + #undef DEFAULT_SYMBOL_NAMESPACE + #define DEFAULT_SYMBOL_NAMESPACE USB_COMMON + +Questo va messo prima di un qualsiasi uso di EXPORT_SYMBOL. + +3. Come usare i simboli esportati attraverso uno spazio dei nomi +================================================================ + +Per usare i simboli esportati da uno spazio dei nomi, i moduli del +kernel devono esplicitamente importare il relativo spazio dei nomi; altrimenti +il kernel potrebbe rifiutarsi di caricare il modulo. Il codice del +modulo deve usare la macro MODULE_IMPORT_NS per importare lo spazio +dei nomi che contiene i simboli desiderati. Per esempio un modulo che +usa il simbolo usb_stor_suspend deve importare lo spazio dei nomi +USB_STORAGE usando la seguente dichiarazione:: + + MODULE_IMPORT_NS(USB_STORAGE); + +Questo creerà un'etichetta `modinfo` per ogni spazio dei nomi +importato. Un risvolto di questo fatto è che gli spazi dei +nomi importati da un modulo possono essere ispezionati tramite +modinfo:: + + $ modinfo drivers/usb/storage/ums-karma.ko + [...] + import_ns: USB_STORAGE + [...] + + +Si consiglia di posizionare la dichiarazione MODULE_IMPORT_NS() vicino +ai metadati del modulo come MODULE_AUTHOR() o MODULE_LICENSE(). Fate +riferimento alla sezione 5. per creare automaticamente le importazioni +mancanti. + +4. Caricare moduli che usano simboli provenienti da spazi dei nomi +================================================================== + +Quando un modulo viene caricato (per esempio usando `insmod`), il kernel +verificherà la disponibilità di ogni simbolo usato e se lo spazio dei nomi +che potrebbe contenerli è stato importato. Il comportamento di base del kernel +è di rifiutarsi di caricare quei moduli che non importano tutti gli spazi dei +nomi necessari. L'errore verrà annotato e il caricamento fallirà con l'errore +EINVAL. Per caricare i moduli che non soddisfano questo requisito esiste +un'opzione di configurazione: impostare +MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS=y caricherà i moduli comunque ma +emetterà un avviso. + +5. Creare automaticamente la dichiarazione MODULE_IMPORT_NS +=========================================================== + +La mancanza di un'importazione può essere individuata facilmente al momento +della compilazione. Infatti, modpost emetterà un avviso se il modulo usa +un simbolo da uno spazio dei nomi che non è stato importato. +La dichiarazione MODULE_IMPORT_NS() viene solitamente aggiunta in un posto +ben definito (assieme agli altri metadati del modulo). Per facilitare +la vita di chi scrive moduli (e i manutentori di sottosistemi), esistono uno +script e un target make per correggere le importazioni mancanti. Questo può +essere fatto con:: + + $ make nsdeps + +Lo scenario tipico di chi scrive un modulo potrebbe essere:: + + - scrivere codice che dipende da un simbolo appartenente ad uno spazio + dei nomi non importato + - eseguire `make` + - aver notato un avviso da modpost che parla di un'importazione + mancante + - eseguire `make nsdeps` per aggiungere import nel posto giusto + +Per i manutentori di sottosistemi che vogliono aggiungere uno spazio dei nomi, +l'approccio è simile. Di nuovo, eseguendo `make nsdeps` aggiungerà le +importazioni mancanti nei moduli inclusi nel kernel:: + + - spostare o aggiungere simboli ad uno spazio dei nomi (per esempio + usando EXPORT_SYMBOL_NS()) + - eseguire `make` (preferibilmente con allmodconfig per coprire tutti + i moduli del kernel) + - aver notato un avviso da modpost che parla di un'importazione + mancante + - eseguire `make nsdeps` per aggiungere import nel posto giusto + +Potete anche eseguire nsdeps per moduli esterni. Solitamente si usa così:: + + $ make -C <path_to_kernel_src> M=$PWD nsdeps diff --git a/Documentation/translations/it_IT/index.rst b/Documentation/translations/it_IT/index.rst index 409eaac03e9f..bb8fa7346939 100644 --- a/Documentation/translations/it_IT/index.rst +++ b/Documentation/translations/it_IT/index.rst @@ -121,9 +121,10 @@ file sorgenti, informazioni aggiuntive vengono aggiunte solo se necessarie (o almeno ci proviamo — probabilmente *non* tutto quello che è davvero necessario). -.. warning:: +.. toctree:: + :maxdepth: 2 - TODO ancora da tradurre + core-api/index Documentazione specifica per architettura ----------------------------------------- diff --git a/Documentation/translations/it_IT/kernel-hacking/hacking.rst b/Documentation/translations/it_IT/kernel-hacking/hacking.rst index e9a2e92134f0..6aab27a8d323 100644 --- a/Documentation/translations/it_IT/kernel-hacking/hacking.rst +++ b/Documentation/translations/it_IT/kernel-hacking/hacking.rst @@ -634,7 +634,7 @@ Definita in ``include/linux/export.h`` Questa è una variate di `EXPORT_SYMBOL()` che permette di specificare uno spazio dei nomi. Lo spazio dei nomi è documentato in -:doc:`../../../core-api/symbol-namespaces` +:doc:`../core-api/symbol-namespaces` :c:func:`EXPORT_SYMBOL_NS_GPL()` -------------------------------- @@ -643,7 +643,7 @@ Definita in ``include/linux/export.h`` Questa è una variate di `EXPORT_SYMBOL_GPL()` che permette di specificare uno spazio dei nomi. Lo spazio dei nomi è documentato in -:doc:`../../../core-api/symbol-namespaces` +:doc:`../core-api/symbol-namespaces` Procedure e convenzioni ======================= diff --git a/Documentation/translations/it_IT/process/coding-style.rst b/Documentation/translations/it_IT/process/coding-style.rst index 6f4f85832dee..a346f1f2ce21 100644 --- a/Documentation/translations/it_IT/process/coding-style.rst +++ b/Documentation/translations/it_IT/process/coding-style.rst @@ -1097,7 +1097,7 @@ la direttiva condizionale su di esse. Se avete una variabile o funzione che potrebbe non essere usata in alcune configurazioni, e quindi il compilatore potrebbe avvisarvi circa la definizione -inutilizzata, marcate questa definizione come __maybe_used piuttosto che +inutilizzata, marcate questa definizione come __maybe_unused piuttosto che racchiuderla in una direttiva condizionale del preprocessore. (Comunque, se una variabile o funzione è *sempre* inutilizzata, rimuovetela). diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt index 34d041d68f78..9dcc7c9d52e6 100644 --- a/Documentation/translations/ko_KR/memory-barriers.txt +++ b/Documentation/translations/ko_KR/memory-barriers.txt @@ -570,14 +570,14 @@ ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE [*] 버스 마스터링 DMA 와 일관성에 대해서는 다음을 참고하시기 바랍니다: Documentation/driver-api/pci/pci.rst - Documentation/DMA-API-HOWTO.txt - Documentation/DMA-API.txt + Documentation/core-api/dma-api-howto.rst + Documentation/core-api/dma-api.rst 데이터 의존성 배리어 (역사적) ----------------------------- -리눅스 커널 v4.15 기준으로, smp_read_barrier_depends() 가 READ_ONCE() 에 +리눅스 커널 v4.15 기준으로, smp_mb() 가 DEC Alpha 용 READ_ONCE() 코드에 추가되었는데, 이는 이 섹션에 주의를 기울여야 하는 사람들은 DEC Alpha 아키텍쳐 전용 코드를 만드는 사람들과 READ_ONCE() 자체를 만드는 사람들 뿐임을 의미합니다. 그런 분들을 위해, 그리고 역사에 관심 있는 분들을 위해, 여기 데이터 의존성 @@ -1907,7 +1907,7 @@ Mandatory 배리어들은 SMP 시스템에서도 UP 시스템에서도 SMP 효 writel_relaxed() 와 같은 완화된 I/O 접근자들에 대한 자세한 내용을 위해서는 "커널 I/O 배리어의 효과" 섹션을, consistent memory 에 대한 자세한 내용을 - 위해선 Documentation/DMA-API.txt 문서를 참고하세요. + 위해선 Documentation/core-api/dma-api.rst 문서를 참고하세요. ========================= @@ -2664,144 +2664,6 @@ CPU 코어는 프로그램의 인과성이 유지된다고만 여겨진다면 수도 있습니다. -캐시 일관성 ------------ - -하지만 삶은 앞에서 이야기한 것처럼 단순하지 않습니다: 캐시들은 일관적일 것으로 -기대되지만, 그 일관성이 순서에도 적용될 거라는 보장은 없습니다. 한 CPU 에서 -만들어진 변경 사항은 최종적으로는 시스템의 모든 CPU 에게 보여지게 되지만, 다른 -CPU 들에게도 같은 순서로 보이게 될 거라는 보장은 없다는 뜻입니다. - - -두개의 CPU (1 & 2) 가 달려 있고, 각 CPU 에 두개의 데이터 캐시(CPU 1 은 A/B 를, -CPU 2 는 C/D 를 갖습니다)가 병렬로 연결되어 있는 시스템을 다룬다고 생각해 -봅시다: - - : - : +--------+ - : +---------+ | | - +--------+ : +--->| Cache A |<------->| | - | | : | +---------+ | | - | CPU 1 |<---+ | | - | | : | +---------+ | | - +--------+ : +--->| Cache B |<------->| | - : +---------+ | | - : | Memory | - : +---------+ | System | - +--------+ : +--->| Cache C |<------->| | - | | : | +---------+ | | - | CPU 2 |<---+ | | - | | : | +---------+ | | - +--------+ : +--->| Cache D |<------->| | - : +---------+ | | - : +--------+ - : - -이 시스템이 다음과 같은 특성을 갖는다 생각해 봅시다: - - (*) 홀수번 캐시라인은 캐시 A, 캐시 C 또는 메모리에 위치할 수 있음; - - (*) 짝수번 캐시라인은 캐시 B, 캐시 D 또는 메모리에 위치할 수 있음; - - (*) CPU 코어가 한개의 캐시에 접근하는 동안, 다른 캐시는 - 더티 캐시라인을 - 메모리에 내리거나 추측성 로드를 하거나 하기 위해 - 시스템의 다른 부분에 - 액세스 하기 위해 버스를 사용할 수 있음; - - (*) 각 캐시는 시스템의 나머지 부분들과 일관성을 맞추기 위해 해당 캐시에 - 적용되어야 할 오퍼레이션들의 큐를 가짐; - - (*) 이 일관성 큐는 캐시에 이미 존재하는 라인에 가해지는 평범한 로드에 의해서는 - 비워지지 않는데, 큐의 오퍼레이션들이 이 로드의 결과에 영향을 끼칠 수 있다 - 할지라도 그러함. - -이제, 첫번째 CPU 에서 두개의 쓰기 오퍼레이션을 만드는데, 해당 CPU 의 캐시에 -요청된 순서로 오퍼레이션이 도달됨을 보장하기 위해 두 오퍼레이션 사이에 쓰기 -배리어를 사용하는 상황을 상상해 봅시다: - - CPU 1 CPU 2 COMMENT - =============== =============== ======================================= - u == 0, v == 1 and p == &u, q == &u - v = 2; - smp_wmb(); v 의 변경이 p 의 변경 전에 보일 것을 - 분명히 함 - <A:modify v=2> v 는 이제 캐시 A 에 독점적으로 존재함 - p = &v; - <B:modify p=&v> p 는 이제 캐시 B 에 독점적으로 존재함 - -여기서의 쓰기 메모리 배리어는 CPU 1 의 캐시가 올바른 순서로 업데이트 된 것으로 -시스템의 다른 CPU 들이 인지하게 만듭니다. 하지만, 이제 두번째 CPU 가 그 값들을 -읽으려 하는 상황을 생각해 봅시다: - - CPU 1 CPU 2 COMMENT - =============== =============== ======================================= - ... - q = p; - x = *q; - -위의 두개의 읽기 오퍼레이션은 예상된 순서로 일어나지 못할 수 있는데, 두번째 CPU -의 한 캐시에 다른 캐시 이벤트가 발생해 v 를 담고 있는 캐시라인의 해당 캐시에의 -업데이트가 지연되는 사이, p 를 담고 있는 캐시라인은 두번째 CPU 의 다른 캐시에 -업데이트 되어버렸을 수 있기 때문입니다. - - CPU 1 CPU 2 COMMENT - =============== =============== ======================================= - u == 0, v == 1 and p == &u, q == &u - v = 2; - smp_wmb(); - <A:modify v=2> <C:busy> - <C:queue v=2> - p = &v; q = p; - <D:request p> - <B:modify p=&v> <D:commit p=&v> - <D:read p> - x = *q; - <C:read *q> 캐시에 업데이트 되기 전의 v 를 읽음 - <C:unbusy> - <C:commit v=2> - -기본적으로, 두개의 캐시라인 모두 CPU 2 에 최종적으로는 업데이트 될 것이지만, -별도의 개입 없이는, 업데이트의 순서가 CPU 1 에서 만들어진 순서와 동일할 -것이라는 보장이 없습니다. - - -여기에 개입하기 위해선, 데이터 의존성 배리어나 읽기 배리어를 로드 오퍼레이션들 -사이에 넣어야 합니다 (v4.15 부터는 READ_ONCE() 매크로에 의해 무조건적으로 -그렇게 됩니다). 이렇게 함으로써 캐시가 다음 요청을 처리하기 전에 일관성 큐를 -처리하도록 강제하게 됩니다. - - CPU 1 CPU 2 COMMENT - =============== =============== ======================================= - u == 0, v == 1 and p == &u, q == &u - v = 2; - smp_wmb(); - <A:modify v=2> <C:busy> - <C:queue v=2> - p = &v; q = p; - <D:request p> - <B:modify p=&v> <D:commit p=&v> - <D:read p> - smp_read_barrier_depends() - <C:unbusy> - <C:commit v=2> - x = *q; - <C:read *q> 캐시에 업데이트 된 v 를 읽음 - - -이런 부류의 문제는 DEC Alpha 계열 프로세서들에서 발견될 수 있는데, 이들은 -데이터 버스를 좀 더 잘 사용해 성능을 개선할 수 있는, 분할된 캐시를 가지고 있기 -때문입니다. 대부분의 CPU 는 하나의 읽기 오퍼레이션의 메모리 액세스가 다른 읽기 -오퍼레이션에 의존적이라면 데이터 의존성 배리어를 내포시킵니다만, 모두가 그런건 -아니기 때문에 이점에 의존해선 안됩니다. - -다른 CPU 들도 분할된 캐시를 가지고 있을 수 있지만, 그런 CPU 들은 평범한 메모리 -액세스를 위해서도 이 분할된 캐시들 사이의 조정을 해야만 합니다. Alpha 는 가장 -약한 메모리 순서 시맨틱 (semantic) 을 선택함으로써 메모리 배리어가 명시적으로 -사용되지 않았을 때에는 그런 조정이 필요하지 않게 했으며, 이는 Alpha 가 당시에 -더 높은 CPU 클락 속도를 가질 수 있게 했습니다. 하지만, (다시 말하건대, v4.15 -이후부터는) Alpha 아키텍쳐 전용 코드와 READ_ONCE() 매크로 내부에서를 제외하고는 -smp_read_barrier_depends() 가 사용되지 않아야 함을 알아두시기 바랍니다. - - 캐시 일관성 VS DMA ------------------ @@ -2962,10 +2824,8 @@ Alpha CPU 의 일부 버전은 분할된 데이터 캐시를 가지고 있어서 데이터의 발견을 올바른 순서로 일어나게 하기 때문입니다. 리눅스 커널의 메모리 배리어 모델은 Alpha 에 기초해서 정의되었습니다만, v4.15 -부터는 리눅스 커널이 READ_ONCE() 내에 smp_read_barrier_depends() 를 추가해서 -Alpha 의 메모리 모델로의 영향력이 크게 줄어들긴 했습니다. - -위의 "캐시 일관성" 서브섹션을 참고하세요. +부터는 Alpha 용 READ_ONCE() 코드 내에 smp_mb() 가 추가되어서 메모리 모델로의 +Alpha 의 영향력이 크게 줄어들었습니다. 가상 머신 게스트 diff --git a/Documentation/translations/zh_CN/admin-guide/clearing-warn-once.rst b/Documentation/translations/zh_CN/admin-guide/clearing-warn-once.rst new file mode 100644 index 000000000000..659264d5f994 --- /dev/null +++ b/Documentation/translations/zh_CN/admin-guide/clearing-warn-once.rst @@ -0,0 +1,9 @@ +清除 WARN_ONCE +-------------- + +WARN_ONCE / WARN_ON_ONCE / printk_once 仅仅打印一次消息. + +echo 1 > /sys/kernel/debug/clear_warn_once + +可以清除这种状态并且再次允许打印一次告警信息，这对于运行测试集后重现问题 +很有用。 diff --git a/Documentation/translations/zh_CN/admin-guide/cpu-load.rst b/Documentation/translations/zh_CN/admin-guide/cpu-load.rst new file mode 100644 index 000000000000..0116d0477799 --- /dev/null +++ b/Documentation/translations/zh_CN/admin-guide/cpu-load.rst @@ -0,0 +1,105 @@ +======= +CPU 负载 +======= + +Linux通过``/proc/stat``和``/proc/uptime``导出各种信息，用户空间工具 +如top(1)使用这些信息计算系统花费在某个特定状态的平均时间。 +例如： + + $ iostat + Linux 2.6.18.3-exp (linmac) 02/20/2007 + + avg-cpu: %user %nice %system %iowait %steal %idle + 10.01 0.00 2.92 5.44 0.00 81.63 + + ... + +这里系统认为在默认采样周期內有10.01%的时间工作在用户空间，2.92%的时 +间用在系统空间，总体上有81.63%的时间是空闲的。 + +大多数情况下``/proc/stat``的信息几乎真实反映了系统信息，然而，由于内 +核采集这些数据的方式/时间的特点，有时这些信息根本不可靠。 + +那么这些信息是如何被搜集的呢？每当时间中断触发时，内核查看此刻运行的 +进程类型，并增加与此类型/状态进程对应的计数器的值。这种方法的问题是 +在两次时间中断之间系统（进程）能够在多种状态之间切换多次，而计数器只 +增加最后一种状态下的计数。 + +举例 +--- + +假设系统有一个进程以如下方式周期性地占用cpu:: + + 两个时钟中断之间的时间线 + |-----------------------| + ^ ^ + |_ 开始运行 | + |_ 开始睡眠 + （很快会被唤醒） + +在上面的情况下，根据``/proc/stat``的信息（由于当系统处于空闲状态时， +时间中断经常会发生）系统的负载将会是0 + +大家能够想象内核的这种行为会发生在许多情况下，这将导致``/proc/stat`` +中存在相当古怪的信息:: + + /* gcc -o hog smallhog.c */ + #include <time.h> + #include <limits.h> + #include <signal.h> + #include <sys/time.h> + #define HIST 10 + + static volatile sig_atomic_t stop; + + static void sighandler (int signr) + { + (void) signr; + stop = 1; + } + static unsigned long hog (unsigned long niters) + { + stop = 0; + while (!stop && --niters); + return niters; + } + int main (void) + { + int i; + struct itimerval it = { .it_interval = { .tv_sec = 0, .tv_usec = 1 }, + .it_value = { .tv_sec = 0, .tv_usec = 1 } }; + sigset_t set; + unsigned long v[HIST]; + double tmp = 0.0; + unsigned long n; + signal (SIGALRM, &sighandler); + setitimer (ITIMER_REAL, &it, NULL); + + hog (ULONG_MAX); + for (i = 0; i < HIST; ++i) v[i] = ULONG_MAX - hog (ULONG_MAX); + for (i = 0; i < HIST; ++i) tmp += v[i]; + tmp /= HIST; + n = tmp - (tmp / 3.0); + + sigemptyset (&set); + sigaddset (&set, SIGALRM); + + for (;;) { + hog (n); + sigwait (&set, &i); + } + return 0; + } + + +参考 +--- + +- http://lkml.org/lkml/2007/2/12/6 +- Documentation/filesystems/proc.rst (1.8) + + +谢谢 +--- + +Con Kolivas, Pavel Machek diff --git a/Documentation/translations/zh_CN/admin-guide/index.rst b/Documentation/translations/zh_CN/admin-guide/index.rst new file mode 100644 index 000000000000..7d502fa5da64 --- /dev/null +++ b/Documentation/translations/zh_CN/admin-guide/index.rst @@ -0,0 +1,125 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: :ref:`Documentation/admin-guide/index.rst` +:Translator: Alex Shi <alex.shi@linux.alibaba.com> + + +Linux 内核用户和管理员指南 +========================== + +下面是一组随时间添加到内核中的面向用户的文档的集合。到目前为止，还没有一个 +整体的顺序或组织 - 这些材料不是一个单一的，连贯的文件！幸运的话，情况会随着 +时间的推移而迅速改善。 + +这个初始部分包含总体信息，包括描述内核的README， 关于内核参数的文档等。 + +Todolist: + + README + kernel-parameters + devices + sysctl/index + +本节介绍CPU漏洞及其缓解措施。 + +Todolist: + + hw-vuln/index + +下面的一组文档，针对的是试图跟踪问题和bug的用户。 + +Todolist: + + reporting-bugs + security-bugs + bug-hunting + bug-bisect + tainted-kernels + ramoops + dynamic-debug-howto + init + kdump/index + perf/index + +这是应用程序开发人员感兴趣的章节的开始。可以在这里找到涵盖内核ABI各个 +方面的文档。 + +Todolist: + + sysfs-rules + +本手册的其余部分包括各种指南，介绍如何根据您的喜好配置内核的特定行为。 + + +.. toctree:: + :maxdepth: 1 + + clearing-warn-once + cpu-load + +Todolist: + + acpi/index + aoe/index + auxdisplay/index + bcache + binderfs + binfmt-misc + blockdev/index + bootconfig + braille-console + btmrvl + cgroup-v1/index + cgroup-v2 + cifs/index + cputopology + dell_rbu + device-mapper/index + edid + efi-stub + ext4 + nfs/index + gpio/index + highuid + hw_random + initrd + iostats + java + jfs + kernel-per-CPU-kthreads + laptops/index + lcd-panel-cgram + ldm + lockup-watchdogs + LSM/index + md + media/index + mm/index + module-signing + mono + namespaces/index + numastat + parport + perf-security + pm/index + pnp + rapidio + ras + rtc + serial-console + svga + sysrq + thunderbolt + ufs + unicode + vga-softcursor + video-output + wimax/index + xfs + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/translations/zh_CN/arm/Booting b/Documentation/translations/zh_CN/arm/Booting index 562e9a2957e6..c3d26ce5f6de 100644 --- a/Documentation/translations/zh_CN/arm/Booting +++ b/Documentation/translations/zh_CN/arm/Booting @@ -124,7 +124,7 @@ bootloader 必须传递一个系统内存的位置和最小值，以及根文件 bootloader 必须以 64bit 地址对齐的形式加载一个设备树映像(dtb)到系统 RAM 中，并用启动数据初始化它。dtb 格式在文档 -Documentation/devicetree/booting-without-of.txt 中。内核将会在 +Documentation/devicetree/booting-without-of.rst 中。内核将会在 dtb 物理地址处查找 dtb 魔数值（0xd00dfeed），以确定 dtb 是否已经代替 标签列表被传递进来。 diff --git a/Documentation/translations/zh_CN/filesystems/sysfs.txt b/Documentation/translations/zh_CN/filesystems/sysfs.txt index fcf620049d11..9481e3ed2a06 100644 --- a/Documentation/translations/zh_CN/filesystems/sysfs.txt +++ b/Documentation/translations/zh_CN/filesystems/sysfs.txt @@ -213,10 +213,12 @@ Sysfs 将会为每次读写操作调用一次这个方法。这使得这些方 - 缓冲区应总是 PAGE_SIZE 大小。对于i386，这个值为4096。 -- show() 方法应该返回写入缓冲区的字节数，也就是 snprintf()的 +- show() 方法应该返回写入缓冲区的字节数，也就是 scnprintf()的 返回值。 -- show() 应始终使用 snprintf()。 +- show() 方法在将格式化返回值返回用户空间的时候，禁止使用snprintf()。 + 如果可以保证不会发生缓冲区溢出，可以使用sprintf()，否则必须使用 + scnprintf()。 - store() 应返回缓冲区的已用字节数。如果整个缓存都已填满，只需返回 count 参数。 diff --git a/Documentation/translations/zh_CN/index.rst b/Documentation/translations/zh_CN/index.rst index 76850a5dd982..85643e46e308 100644 --- a/Documentation/translations/zh_CN/index.rst +++ b/Documentation/translations/zh_CN/index.rst @@ -10,9 +10,13 @@ 人员做出贡献。 与任何大型社区一样，知道如何完成任务将使得更改合并的过程变得更 加容易。 +翻译计划: +内核中文文档欢迎任何翻译投稿，特别是关于内核用户和管理员指南部分。 + .. toctree:: :maxdepth: 2 + admin-guide/index process/index filesystems/index diff --git a/Documentation/translations/zh_CN/process/2.Process.rst b/Documentation/translations/zh_CN/process/2.Process.rst index ceb733bb0294..ebe2e0254b3e 100644 --- a/Documentation/translations/zh_CN/process/2.Process.rst +++ b/Documentation/translations/zh_CN/process/2.Process.rst @@ -212,7 +212,7 @@ Next 树 当前-mm 补丁可在“mmotm”（-mm of the moment）目录中找到，地址： - http://www.ozlabs.org/~akpm/mmotm/ + https://www.ozlabs.org/~akpm/mmotm/ 然而，使用mmotm树可能是一种令人沮丧的体验；它甚至可能无法编译。 @@ -220,7 +220,7 @@ Next 树 linux-next 是下一个合并窗口关闭后主线的快照。linux-next树在Linux-kernel 和 Linux-next 邮件列表中发布，可从以下位置下载： - http://www.kernel.org/pub/linux/kernel/next/ + https://www.kernel.org/pub/linux/kernel/next/ Linux-next 已经成为内核开发过程中不可或缺的一部分；在一个给定的合并窗口中合并 的所有补丁都应该在合并窗口打开之前的一段时间内找到进入Linux-next 的方法。 @@ -260,7 +260,7 @@ staging驱动程序。因此，在成为一名合适的主线驱动的路上，s 现在几乎所有的Linux发行版都打包了Git。主页位于： - http://git-scm.com/ + https://git-scm.com/ 那个页面有指向文档和教程的指针。 @@ -272,7 +272,7 @@ Mercurial与Git共享许多特性，但它提供了一个界面，许多人觉 另一个值得了解的工具是quilt: - http://savannah.nongnu.org/projects/quilt + https://savannah.nongnu.org/projects/quilt Quilt 是一个补丁管理系统，而不是源代码管理系统。它不会随着时间的推移跟踪历史； 相反，它面向根据不断发展的代码库跟踪一组特定的更改。一些主要的子系统维护人员 diff --git a/Documentation/translations/zh_CN/process/4.Coding.rst b/Documentation/translations/zh_CN/process/4.Coding.rst index b82b1dde3122..959a06ba025c 100644 --- a/Documentation/translations/zh_CN/process/4.Coding.rst +++ b/Documentation/translations/zh_CN/process/4.Coding.rst @@ -224,7 +224,7 @@ scripts/coccinelle目录下已经打包了相当多的内核“语义补丁” 或Blackfin开发板，您仍然可以执行编译步骤。可以在以下位置找到一组用于x86系统的 大型交叉编译器： - http://www.kernel.org/pub/tools/crosstool/ + https://www.kernel.org/pub/tools/crosstool/ 花一些时间安装和使用这些编译器将有助于避免以后的尴尬。 diff --git a/Documentation/translations/zh_CN/process/7.AdvancedTopics.rst b/Documentation/translations/zh_CN/process/7.AdvancedTopics.rst index 956815edbd18..2f0ef750746f 100644 --- a/Documentation/translations/zh_CN/process/7.AdvancedTopics.rst +++ b/Documentation/translations/zh_CN/process/7.AdvancedTopics.rst @@ -25,9 +25,9 @@ 将是Git如何特别适合内核开发过程。想要加快Git的开发人员可以在以下网站上找到 更多信息： - http://git-scm.com/ + https://git-scm.com/ - http://www.kernel.org/pub/software/scm/git/docs/user-manual.html + https://www.kernel.org/pub/software/scm/git/docs/user-manual.html 在尝试使用它使补丁可供其他人使用之前，第一要务是阅读上述站点，对Git的工作 方式有一个扎实的了解。使用Git的开发人员应该能够获得主线存储库的副本，探索 @@ -42,7 +42,7 @@ 如果您有一个可以访问Internet的系统，那么使用git守护进程设置这样的服务器相 对简单。否则，免费的公共托管网站（例如github）开始出现在网络上。成熟的开发 人员可以在kernel.org上获得一个帐户，但这些帐户并不容易找到；有关更多信息， -请参阅 http://kernel.org/faq/ +请参阅 https://kernel.org/faq/ 正常的Git工作流程涉及到许多分支的使用。每一条开发线都可以分为单独的“主题 分支”，并独立维护。Git的分支机构很便宜，没有理由不免费使用它们。而且，在 diff --git a/Documentation/translations/zh_CN/process/8.Conclusion.rst b/Documentation/translations/zh_CN/process/8.Conclusion.rst index 2bbd76161e10..90cec3de6106 100644 --- a/Documentation/translations/zh_CN/process/8.Conclusion.rst +++ b/Documentation/translations/zh_CN/process/8.Conclusion.rst @@ -17,16 +17,16 @@ 记录的；“make htmldocs”或“make pdfdocs”可用于以HTML或PDF格式生成这些文档（ 尽管某些发行版提供的tex版本会遇到内部限制，无法正确处理文档）。 -不同的网站在各个细节层次上讨论内核开发。您的作者想谦虚地建议用 http://lwn.net/ +不同的网站在各个细节层次上讨论内核开发。您的作者想谦虚地建议用 https://lwn.net/ 作为来源；有关许多特定内核主题的信息可以通过以下网址的lwn内核索引找到： http://lwn.net/kernel/index/ 除此之外，内核开发人员的一个宝贵资源是： - http://kernelnewbies.org/ + https://kernelnewbies.org/ -当然，我们不应该忘记 http://kernel.org/ 这是内核发布信息的最终位置。 +当然，我们不应该忘记 https://kernel.org/ 这是内核发布信息的最终位置。 关于内核开发有很多书： @@ -42,9 +42,9 @@ 有关git的文档，请访问： - http://www.kernel.org/pub/software/scm/git/docs/ + https://www.kernel.org/pub/software/scm/git/docs/ - http://www.kernel.org/pub/software/scm/git/docs/user-manual.html + https://www.kernel.org/pub/software/scm/git/docs/user-manual.html 结论 ==== diff --git a/Documentation/translations/zh_CN/process/coding-style.rst b/Documentation/translations/zh_CN/process/coding-style.rst index eae10bc7f86f..406d43a02c02 100644 --- a/Documentation/translations/zh_CN/process/coding-style.rst +++ b/Documentation/translations/zh_CN/process/coding-style.rst @@ -946,7 +946,7 @@ Addison-Wesley, Inc., 1999. ISBN 0-201-61586-X. GNU 手册 - 遵循 K&R 标准和此文本 - cpp, gcc, gcc internals and indent, -都可以从 http://www.gnu.org/manual/ 找到 +都可以从 https://www.gnu.org/manual/ 找到 WG14 是 C 语言的国际标准化工作组，URL: http://www.open-std.org/JTC1/SC22/WG14/ diff --git a/Documentation/translations/zh_CN/process/howto.rst b/Documentation/translations/zh_CN/process/howto.rst index a8e6ab818983..ee3dee476d57 100644 --- a/Documentation/translations/zh_CN/process/howto.rst +++ b/Documentation/translations/zh_CN/process/howto.rst @@ -69,7 +69,7 @@ Linux内核源代码都是在GPL（通用公共许可证）的保护下发布的 邮件组里的人并不是律师，不要期望他们的话有法律效力。 对于GPL的常见问题和解答，请访问以下链接： - http://www.gnu.org/licenses/gpl-faq.html + https://www.gnu.org/licenses/gpl-faq.html 文档 @@ -109,7 +109,7 @@ Linux内核代码中包含有大量的文档。这些文档对于学习如何与 其他关于如何正确地生成补丁的优秀文档包括： "The Perfect Patch" - http://www.ozlabs.org/~akpm/stuff/tpp.txt + https://www.ozlabs.org/~akpm/stuff/tpp.txt "Linux kernel patch submission format" @@ -163,7 +163,7 @@ ReST格式的文档会生成在 Documentation/output. 目录中。 ------------------ 如果你对Linux内核开发一无所知，你应该访问“Linux内核新手”计划： - http://kernelnewbies.org + https://kernelnewbies.org 它拥有一个可以问各种最基本的内核开发问题的邮件列表（在提问之前一定要记得 查找已往的邮件，确认是否有人已经回答过相同的问题）。它还拥有一个可以获得 @@ -176,7 +176,7 @@ ReST格式的文档会生成在 Documentation/output. 目录中。 如果你想加入内核开发社区并协助完成一些任务，却找不到从哪里开始，可以访问 “Linux内核房管员”计划： - http://kernelnewbies.org/KernelJanitors + https://kernelnewbies.org/KernelJanitors 这是极佳的起点。它提供一个相对简单的任务列表，列出内核代码中需要被重新 整理或者改正的地方。通过和负责这个计划的开发者们一同工作，你会学到将补丁 @@ -212,7 +212,7 @@ ReST格式的文档会生成在 Documentation/output. 目录中。 - 每当一个新版本的内核被发布，为期两周的集成窗口将被打开。在这段时间里 维护者可以向Linus提交大段的修改，通常这些修改已经被放到-mm内核中几个 星期了。提交大量修改的首选方式是使用git工具（内核的代码版本管理工具 - ，更多的信息可以在 http://git-scm.com/ 获取），不过使用普通补丁也是 + ，更多的信息可以在 https://git-scm.com/ 获取），不过使用普通补丁也是 可以的。 - 两个星期以后-rc1版本内核发布。之后只有不包含可能影响整个内核稳定性的 新功能的补丁才可能被接受。请注意一个全新的驱动程序（或者文件系统）有 @@ -472,7 +472,7 @@ Linux内核社区并不喜欢一下接收大段的代码。修改需要被恰当 想了解它具体应该看起来像什么，请查阅以下文档中的“ChangeLog”章节： “The Perfect Patch” - http://www.ozlabs.org/~akpm/stuff/tpp.txt + https://www.ozlabs.org/~akpm/stuff/tpp.txt 这些事情有时候做起来很难。要在任何方面都做到完美可能需要好几年时间。这是 diff --git a/Documentation/translations/zh_CN/process/submitting-drivers.rst b/Documentation/translations/zh_CN/process/submitting-drivers.rst index d99885c27aed..98341e7cd812 100644 --- a/Documentation/translations/zh_CN/process/submitting-drivers.rst +++ b/Documentation/translations/zh_CN/process/submitting-drivers.rst @@ -19,8 +19,8 @@ ============================= 这篇文档将会解释如何向不同的内核源码树提交设备驱动程序。请注意，如果你感 -兴趣的是显卡驱动程序，你也许应该访问 XFree86 项目(http://www.xfree86.org/) -和／或 X.org 项目 (http://x.org)。 +兴趣的是显卡驱动程序，你也许应该访问 XFree86 项目(https://www.xfree86.org/) +和／或 X.org 项目 (https://x.org)。 另请参阅 Documentation/translations/zh_CN/process/submitting-patches.rst 文档。 @@ -29,7 +29,7 @@ ---------- 块设备和字符设备的主设备号与从设备号是由 Linux 命名编号分配权威 LANANA（ -现在是 Torben Mathiasen）负责分配。申请的网址是 http://www.lanana.org/。 +现在是 Torben Mathiasen）负责分配。申请的网址是 https://www.lanana.org/。 即使不准备提交到主流内核的设备驱动也需要在这里分配设备号。有关详细信息， 请参阅 Documentation/admin-guide/devices.rst。 @@ -133,22 +133,22 @@ Linux 内核邮件列表： [可通过向majordomo@vger.kernel.org发邮件来订阅] Linux 设备驱动程序，第三版（探讨 2.6.10 版内核）： - http://lwn.net/Kernel/LDD3/ （免费版） + https://lwn.net/Kernel/LDD3/ （免费版） LWN.net: - 每周内核开发活动摘要 - http://lwn.net/ + 每周内核开发活动摘要 - https://lwn.net/ 2.6 版中 API 的变更： - http://lwn.net/Articles/2.6-kernel-api/ + https://lwn.net/Articles/2.6-kernel-api/ 将旧版内核的驱动程序移植到 2.6 版： - http://lwn.net/Articles/driver-porting/ + https://lwn.net/Articles/driver-porting/ 内核新手(KernelNewbies): 为新的内核开发者提供文档和帮助 - http://kernelnewbies.org/ + https://kernelnewbies.org/ Linux USB项目： http://www.linux-usb.org/ @@ -157,4 +157,4 @@ Linux USB项目： http://www.fenrus.org/how-to-not-write-a-device-driver-paper.pdf 内核清洁工 (Kernel Janitor): - http://kernelnewbies.org/KernelJanitors + https://kernelnewbies.org/KernelJanitors diff --git a/Documentation/translations/zh_CN/process/submitting-patches.rst b/Documentation/translations/zh_CN/process/submitting-patches.rst index 1bb4271ab420..2e7dbaad4028 100644 --- a/Documentation/translations/zh_CN/process/submitting-patches.rst +++ b/Documentation/translations/zh_CN/process/submitting-patches.rst @@ -91,7 +91,7 @@ :ref:`cn_split_changes` 如果你用 ``git`` , ``git rebase -i`` 可以帮助你这一点。如果你不用 ``git``, -``quilt`` <http://savannah.nongnu.org/projects/quilt> 另外一个流行的选择。 +``quilt`` <https://savannah.nongnu.org/projects/quilt> 另外一个流行的选择。 .. _cn_describe_changes: @@ -649,7 +649,7 @@ pull 请求还应该包含一条整体消息，说明请求中将包含什么， -------- Andrew Morton, "The perfect patch" (tpp). - <http://www.ozlabs.org/~akpm/stuff/tpp.txt> + <https://www.ozlabs.org/~akpm/stuff/tpp.txt> Jeff Garzik, "Linux kernel patch submission format". <https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html> diff --git a/Documentation/translations/zh_CN/process/volatile-considered-harmful.rst b/Documentation/translations/zh_CN/process/volatile-considered-harmful.rst index 48b32ce58ef1..ded3b5d0c9a8 100644 --- a/Documentation/translations/zh_CN/process/volatile-considered-harmful.rst +++ b/Documentation/translations/zh_CN/process/volatile-considered-harmful.rst @@ -94,8 +94,8 @@ bug并且需要对这样的代码额外仔细检查。那些试图使用volatile 注释 ---- -[1] http://lwn.net/Articles/233481/ -[2] http://lwn.net/Articles/233482/ +[1] https://lwn.net/Articles/233481/ +[2] https://lwn.net/Articles/233482/ 致谢 ---- |