summaryrefslogtreecommitdiff
path: root/Documentation/translations
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2020-08-04 22:47:54 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2020-08-04 22:47:54 -0700
commit2324d50d051ec0f14a548e78554fb02513d6dcef (patch)
tree467e5622cf878daed7c00be90a02a1f036de04ad /Documentation/translations
parenta754292348bf88ec6b55563eca4faba7dcfe2ae7 (diff)
parent2c12c8103d8f15790cf880f1545dafa36acb004a (diff)
Merge tag 'docs-5.9' of git://git.lwn.net/linux
Pull documentation updates from Jonathan Corbet: "It's been a busy cycle for documentation - hopefully the busiest for a while to come. Changes include: - Some new Chinese translations - Progress on the battle against double words words and non-HTTPS URLs - Some block-mq documentation - More RST conversions from Mauro. At this point, that task is essentially complete, so we shouldn't see this kind of churn again for a while. Unless we decide to switch to asciidoc or something...:) - Lots of typo fixes, warning fixes, and more" * tag 'docs-5.9' of git://git.lwn.net/linux: (195 commits) scripts/kernel-doc: optionally treat warnings as errors docs: ia64: correct typo mailmap: add entry for <alobakin@marvell.com> doc/zh_CN: add cpu-load Chinese version Documentation/admin-guide: tainted-kernels: fix spelling mistake MAINTAINERS: adjust kprobes.rst entry to new location devices.txt: document rfkill allocation PCI: correct flag name docs: filesystems: vfs: correct flag name docs: filesystems: vfs: correct sync_mode flag names docs: path-lookup: markup fixes for emphasis docs: path-lookup: more markup fixes docs: path-lookup: fix HTML entity mojibake CREDITS: Replace HTTP links with HTTPS ones docs: process: Add an example for creating a fixes tag doc/zh_CN: add Chinese translation prefer section doc/zh_CN: add clearing-warn-once Chinese version doc/zh_CN: add admin-guide index doc:it_IT: process: coding-style.rst: Correct __maybe_unused compiler label futex: MAINTAINERS: Re-add selftests directory ...
Diffstat (limited to 'Documentation/translations')
-rw-r--r--Documentation/translations/it_IT/core-api/index.rst18
-rw-r--r--Documentation/translations/it_IT/core-api/symbol-namespaces.rst166
-rw-r--r--Documentation/translations/it_IT/index.rst5
-rw-r--r--Documentation/translations/it_IT/kernel-hacking/hacking.rst4
-rw-r--r--Documentation/translations/it_IT/process/coding-style.rst2
-rw-r--r--Documentation/translations/ko_KR/memory-barriers.txt6
-rw-r--r--Documentation/translations/zh_CN/admin-guide/clearing-warn-once.rst9
-rw-r--r--Documentation/translations/zh_CN/admin-guide/cpu-load.rst105
-rw-r--r--Documentation/translations/zh_CN/admin-guide/index.rst125
-rw-r--r--Documentation/translations/zh_CN/arm/Booting2
-rw-r--r--Documentation/translations/zh_CN/filesystems/sysfs.txt6
-rw-r--r--Documentation/translations/zh_CN/index.rst4
-rw-r--r--Documentation/translations/zh_CN/process/2.Process.rst8
-rw-r--r--Documentation/translations/zh_CN/process/4.Coding.rst2
-rw-r--r--Documentation/translations/zh_CN/process/7.AdvancedTopics.rst6
-rw-r--r--Documentation/translations/zh_CN/process/8.Conclusion.rst10
-rw-r--r--Documentation/translations/zh_CN/process/coding-style.rst2
-rw-r--r--Documentation/translations/zh_CN/process/howto.rst12
-rw-r--r--Documentation/translations/zh_CN/process/submitting-drivers.rst18
-rw-r--r--Documentation/translations/zh_CN/process/submitting-patches.rst4
-rw-r--r--Documentation/translations/zh_CN/process/volatile-considered-harmful.rst4
21 files changed, 474 insertions, 44 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 a1f772ef622c..9dcc7c9d52e6 100644
--- a/Documentation/translations/ko_KR/memory-barriers.txt
+++ b/Documentation/translations/ko_KR/memory-barriers.txt
@@ -570,8 +570,8 @@ 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
데이터 의존성 배리어 (역사적)
@@ -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 문서를 참고하세요.
=========================
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/
致谢
----