Commit 647681bf authored by Linus Torvalds's avatar Linus Torvalds

Merge tag 'docs-6.4-2' of git://git.lwn.net/linux

Pull more documentation updates from Jonathan Corbet:
 "A handful of late-arriving documentation fixes, plus one Spanish
  translation that has been ready for some time but got applied late"

* tag 'docs-6.4-2' of git://git.lwn.net/linux:
  docs/sp_SP: Add translation of process/adding-syscalls
  CREDITS: Update email address for Mat Martineau
  Documentation: update kernel stack for x86_64
  docs: Remove unnecessary unicode character
  docs: fix "Reviewd" typo
  Documentation: timers: hrtimers: Make hybrid union historical
  docs/admin-guide/mm/ksm.rst fix intraface -> interface typo
  doc:it_IT: fix some typos
parents e919a3f7 cdc822dd
......@@ -2510,8 +2510,8 @@ D: XF86_8514
D: cfdisk (curses based disk partitioning program)
N: Mat Martineau
E: mat@martineau.name
D: MPTCP subsystem co-maintainer 2020-2023
E: martineau@kernel.org
D: MPTCP subsystem co-maintainer
D: Keyctl restricted keyring and Diffie-Hellman UAPI
D: Bluetooth L2CAP ERTM mode and AMP
S: USA
......
......@@ -20,7 +20,7 @@ content which can be replaced by a single write-protected page (which
is automatically copied if a process later wants to update its
content). The amount of pages that KSM daemon scans in a single pass
and the time between the passes are configured using :ref:`sysfs
intraface <ksm_sysfs>`
interface <ksm_sysfs>`
KSM only merges anonymous (private) pages, never pagecache (file) pages.
KSM's merged pages were originally locked into kernel memory, but can now
......
......@@ -12,7 +12,7 @@ Most of the text from Keith Owens, hacked by AK
x86_64 page size (PAGE_SIZE) is 4K.
Like all other architectures, x86_64 has a kernel stack for every
active thread. These thread stacks are THREAD_SIZE (2*PAGE_SIZE) big.
active thread. These thread stacks are THREAD_SIZE (4*PAGE_SIZE) big.
These stacks contain useful data as long as a thread is alive or a
zombie. While the thread is in user space the kernel stack is empty
except for the thread_info structure at the bottom.
......
......@@ -123,17 +123,12 @@ equivalent to timer_delete() and timer_delete_sync()] - so there's no direct
potential for code sharing either.
Basic data types: every time value, absolute or relative, is in a
special nanosecond-resolution type: ktime_t. The kernel-internal
representation of ktime_t values and operations is implemented via
macros and inline functions, and can be switched between a "hybrid
union" type and a plain "scalar" 64bit nanoseconds representation (at
compile time). The hybrid union type optimizes time conversions on 32bit
CPUs. This build-time-selectable ktime_t storage format was implemented
to avoid the performance impact of 64-bit multiplications and divisions
on 32bit CPUs. Such operations are frequently necessary to convert
between the storage formats provided by kernel and userspace interfaces
and the internal time format. (See include/linux/ktime.h for further
details.)
special nanosecond-resolution 64bit type: ktime_t.
(Originally, the kernel-internal representation of ktime_t values and
operations was implemented via macros and inline functions, and could be
switched between a "hybrid union" type and a plain "scalar" 64bit
nanoseconds representation (at compile time). This was abandoned in the
context of the Y2038 work.)
hrtimers - rounding of timer values
-----------------------------------
......@@ -148,7 +143,7 @@ a given clock has - be it low-res, high-res, or artificially-low-res.
hrtimers - testing and verification
-----------------------------------
We used the high-resolution clock subsystem ontop of hrtimers to verify
We used the high-resolution clock subsystem on top of hrtimers to verify
the hrtimer implementation details in praxis, and we also ran the posix
timer tests in order to ensure specification compliance. We also ran
tests on low-resolution clocks.
......
......@@ -1030,7 +1030,7 @@ alle corse critiche, dovreste usare timer_delete_sync()
(``include/linux/timer.h``) per gestire questo caso.
Prima di rilasciare un temporizzatore dovreste chiamare la funzione
timer_shutdown() o timer_shutdown_sync() di modo che non venga più ricarmato.
timer_shutdown() o timer_shutdown_sync() di modo che non venga più riarmato.
Ogni successivo tentativo di riarmare il temporizzatore verrà silenziosamente
ignorato.
......
......@@ -386,7 +386,7 @@ combinazione con struct_size() e flex_array_size()::
Ci sono due casi speciali dove è necessario usare la macro DECLARE_FLEX_ARRAY()
(da notare che la stessa macro è chiamata __DECLARE_FLEX_ARRAY() nei file di
intestazione UAPI). Uno è quando l'array flessibile è l'unico elemento di una
struttura, e l'altro è quando è parti un unione. Per motivi non tecnici, entrambi
struttura, e l'altro quando è parte di un unione. Per motivi non tecnici, entrambi
i casi d'uso non sono permessi dalla specifica C99. Per esempio, per
convertire il seguente codice::
......
......@@ -532,7 +532,7 @@ manutentori che qualche verifica è stata fatta, fornisce un mezzo per trovare
persone che possano verificare il codice in futuro, e garantisce che queste
stesse persone ricevano credito per il loro lavoro.
Reviewd-by:, invece, indica che la patch è stata revisionata ed è stata
Reviewed-by:, invece, indica che la patch è stata revisionata ed è stata
considerata accettabile in accordo con la dichiarazione dei revisori:
Dichiarazione di svista dei revisori
......@@ -563,13 +563,13 @@ una modifica che si ritiene appropriata e senza alcun problema tecnico
importante. Qualsiasi revisore interessato (quelli che lo hanno fatto)
possono offrire il proprio Reviewed-by per la patch. Questa etichetta serve
a dare credito ai revisori e a informare i manutentori sul livello di revisione
che è stato fatto sulla patch. L'etichetta Reviewd-by, quando fornita da
che è stato fatto sulla patch. L'etichetta Reviewed-by, quando fornita da
revisori conosciuti per la loro conoscenza sulla materia in oggetto e per la
loro serietà nella revisione, accrescerà le probabilità che la vostra patch
venga integrate nel kernel.
Quando si riceve una email sulla lista di discussione da un tester o
un revisore, le etichette Tested-by o Reviewd-by devono essere
un revisore, le etichette Tested-by o Reviewed-by devono essere
aggiunte dall'autore quando invierà nuovamente la patch. Tuttavia, se
la patch è cambiata in modo significativo, queste etichette potrebbero
non avere più senso e quindi andrebbero rimosse. Solitamente si tiene traccia
......
......@@ -450,7 +450,7 @@ Reviewed-by: タグは、それとは異なり、下記のレビューア宣言
状況においてその宣言した目的や機能が正しく実現することに関して、
いかなる保証もしない(特にどこかで明示しない限り)。
Reviewd-by タグはそのパッチがカーネルに対して適切な修正であって、深刻な技術的
Reviewed-by タグはそのパッチがカーネルに対して適切な修正であって、深刻な技術的
問題を残していないという意見の宣言です。興味のあるレビューアは誰でも(レビュー
作業を終えたら)パッチに対して Reviewed-by タグを提示できます。このタグは
レビューアの寄与をクレジットする働き、レビューの進捗の度合いをメンテナに
......
This diff is collapsed.
......@@ -19,3 +19,4 @@
magic-number
programming-language
deprecated
adding-syscalls
......@@ -25,7 +25,7 @@ Linux 魔术数
...
};
当你以后给内核添加增强功能的时候,请遵守这条规则!这样就会节省数不清的调试时间,特别是一些古怪的情况,例如,数组超出范围并且重新写了超出部分。遵守这个规则,这些情况可以被快速地,安全地避免。
当你以后给内核添加增强功能的时候,请遵守这条规则!这样就会节省数不清的调试时间,特别是一些古怪的情况,例如,数组超出范围并且重新写了超出部分。遵守这个规则,这些情况可以被快速地,安全地避免。
Theodore Ts'o
31 Mar 94
......
......@@ -28,7 +28,7 @@ Linux 魔術數
...
};
當你以後給內核添加增強功能的時候,請遵守這條規則!這樣就會節省數不清的調試時間,特別是一些古怪的情況,例如,數組超出範圍並且重新寫了超出部分。遵守這個規則,這些情況可以被快速地,安全地避免。
當你以後給內核添加增強功能的時候,請遵守這條規則!這樣就會節省數不清的調試時間,特別是一些古怪的情況,例如,數組超出範圍並且重新寫了超出部分。遵守這個規則,這些情況可以被快速地,安全地避免。
Theodore Ts'o
31 Mar 94
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment