Commit 37aa7319 authored by Linus Torvalds's avatar Linus Torvalds

Merge tag 'docs-for-linus' of git://git.lwn.net/linux

Pul documentation update from Jon Corbet:
 "Another relatively boring cycle for the docs tree: typo fixes,
  translation updates, etc"

* tag 'docs-for-linus' of git://git.lwn.net/linux:
  modsign: Fix documentation on module signing enforcement parameter.
  Doc: nfs: Fix typos in Documentation/filesystems/nfs
  Documentation: kselftest: Remove duplicate word
  doc: fix grammar
  Documentation: Howto: Fixed subtitles style
  Doc: ARM: Fix a typo in clksrc-change-registers.awk
  Documentation/ko_KR: update maintainer information
  Documentation: Fix int/unsigned int comparison
  Documentation: Chinese translation of arm64/silicon-errata.txt
  Documentation:Update Documentation/zh_CN/arm64/booting.txt
  Documentation: HOWTO: remove obsolete info about regression postings
  Doc: ja_JP: Fix a typo in HOWTO
  Doc: i2c: Fix typo in Documentation/i2c
  Doc: DocBook: Fix a typo in device-drivers.tmpl
  Remove "arch" usage in Documentation/features/list-arch.sh
  README: cosmetic fixes
  Documentation/CodingStyle: add space before parenthesis in example macro
  SubmittingPatches: fix spelling of "git send-email"
parents bb7aeae3 abfa6cd8
......@@ -640,7 +640,7 @@ Things to avoid when using macros:
do { \
if (blah(x) < 0) \
return -EBUGGERED; \
} while(0)
} while (0)
is a _very_ bad idea. It looks like a function call but exits the "calling"
function; don't break the internal parsers of those who will read the code.
......
......@@ -369,7 +369,7 @@ X!Ilib/fonts/fonts.c
!Iinclude/linux/input-polldev.h
!Edrivers/input/input-polldev.c
</sect1>
<sect1><title>Matrix keyboars/keypads</title>
<sect1><title>Matrix keyboards/keypads</title>
!Iinclude/linux/input/matrix_keypad.h
</sect1>
<sect1><title>Sparse keymap support</title>
......
......@@ -68,7 +68,7 @@ For common questions and answers about the GPL, please see:
Documentation
------------
-------------
The Linux kernel source tree has a large range of documents that are
invaluable for learning how to interact with the kernel community. When
......@@ -250,11 +250,6 @@ process is as follows:
release a new -rc kernel every week.
- Process continues until the kernel is considered "ready", the
process should last around 6 weeks.
- Known regressions in each release are periodically posted to the
linux-kernel mailing list. The goal is to reduce the length of
that list to zero before declaring the kernel to be "ready," but, in
the real world, a small number of regressions often remain at
release time.
It is worth mentioning what Andrew Morton wrote on the linux-kernel
mailing list about kernel releases:
......@@ -263,7 +258,7 @@ mailing list about kernel releases:
preconceived timeline."
4.x.y -stable kernel tree
---------------------------
-------------------------
Kernels with 3-part versions are -stable kernels. They contain
relatively small and critical fixes for security problems or significant
regressions discovered in a given 4.x kernel.
......@@ -286,7 +281,7 @@ documents what kinds of changes are acceptable for the -stable tree, and
how the release process works.
4.x -git patches
------------------
----------------
These are daily snapshots of Linus' kernel tree which are managed in a
git repository (hence the name.) These patches are usually released
daily and represent the current state of Linus' tree. They are more
......@@ -318,7 +313,7 @@ accepted, or rejected. Most of these patchwork sites are listed at
http://patchwork.kernel.org/.
4.x -next kernel tree for integration tests
---------------------------------------------
-------------------------------------------
Before updates from subsystem trees are merged into the mainline 4.x
tree, they need to be integration-tested. For this purpose, a special
testing repository exists into which virtually all subsystem trees are
......
......@@ -722,7 +722,7 @@ references.
--------------------------------
It can be helpful to manually add In-Reply-To: headers to a patch
(e.g., when using "git send email") to associate the patch with
(e.g., when using "git send-email") to associate the patch with
previous relevant discussion, e.g. to link a bug fix to the email with
the bug report. However, for a multi-patch series, it is generally
best to avoid using In-Reply-To: to link to older versions of the
......
......@@ -41,7 +41,7 @@ function find_length(f)
else if (f ~ /0xf/)
return 4
printf "unknown legnth " f "\n" > "/dev/stderr"
printf "unknown length " f "\n" > "/dev/stderr"
exit
}
......
......@@ -5,7 +5,7 @@
# (If no arguments are given then it will print the host architecture's status.)
#
ARCH=${1:-$(arch | sed 's/x86_64/x86/' | sed 's/i386/x86/')}
ARCH=${1:-$(uname -m | sed 's/x86_64/x86/' | sed 's/i386/x86/')}
cd $(dirname $0)
echo "#"
......
......@@ -49,13 +49,13 @@ forget_locks:
forget_delegations:
A delegation is used to assure the client that a file, or part of a file,
has not changed since the delegation was awarded. Clearing this list will
force the client to reaquire its delegation before accessing the file
force the client to reacquire its delegation before accessing the file
again.
recall_delegations:
Delegations can be recalled by the server when another client attempts to
access a file. This test will notify the client that its delegation has
been revoked, forcing the client to reaquire the delegation before using
been revoked, forcing the client to reacquire the delegation before using
the file again.
......
......@@ -218,7 +218,7 @@ NFS/RDMA Setup
/vol0 192.168.0.0/255.255.255.0(fsid=0,rw,async,insecure,no_root_squash)
The IP address(es) is(are) the client's IPoIB address for an InfiniBand
HCA or the cleint's iWARP address(es) for an RNIC.
HCA or the client's iWARP address(es) for an RNIC.
NOTE: The "insecure" option must be used because the NFS/RDMA client does
not use a reserved port.
......
......@@ -166,7 +166,7 @@ ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>:
Value gets exported by /proc/net/pnp which is often linked
on embedded systems by /etc/resolv.conf.
<dns1-ip> IP address of secound nameserver.
<dns1-ip> IP address of second nameserver.
Same as above.
......
......@@ -64,8 +64,8 @@ table which are called by the nfs-client pnfs-core to implement the
different layout types.
Files-layout-driver code is in: fs/nfs/filelayout/.. directory
Objects-layout-deriver code is in: fs/nfs/objlayout/.. directory
Blocks-layout-deriver code is in: fs/nfs/blocklayout/.. directory
Objects-layout-driver code is in: fs/nfs/objlayout/.. directory
Blocks-layout-driver code is in: fs/nfs/blocklayout/.. directory
Flexfiles-layout-driver code is in: fs/nfs/flexfilelayout/.. directory
objects-layout setup
......@@ -91,7 +91,7 @@ The API to the login script is as follows:
Usage: $0 -u <URI> -o <OSDNAME> -s <SYSTEMID>
Options:
-u target uri e.g. iscsi://<ip>:<port>
(allways exists)
(always exists)
(More protocols can be defined in the future.
The client does not interpret this string it is
passed unchanged as received from the Server)
......
......@@ -57,7 +57,7 @@ the Kerberos tickets, that needs to be sent through the GSS layer in
order to perform context establishment.
B) It does not properly handle creds where the user is member of more
than a few housand groups (the current hard limit in the kernel is 65K
than a few thousand groups (the current hard limit in the kernel is 65K
groups) due to limitation on the size of the buffer that can be send
back to the kernel (4KiB).
......
......@@ -123,7 +123,7 @@ replicas continue to be exactly same.
2d) A unbindable mount is a unbindable private mount
let's say we have a mount at /mnt and we make is unbindable
let's say we have a mount at /mnt and we make it unbindable
# mount --make-unbindable /mnt
......@@ -197,13 +197,13 @@ replicas continue to be exactly same.
namespaces are made first class objects with user API to
associate/disassociate a namespace with userid, then each user
could have his/her own namespace and tailor it to his/her
requirements. Offcourse its needs support from PAM.
requirements. This needs to be supported in PAM.
D) Versioned files
If the entire mount tree is visible at multiple locations, then
a underlying versioning file system can return different
version of the file depending on the path used to access that
an underlying versioning file system can return different
versions of the file depending on the path used to access that
file.
An example is:
......
......@@ -4,7 +4,7 @@ the /dev interface. You need to load module i2c-dev for this.
Each registered i2c adapter gets a number, counting from 0. You can
examine /sys/class/i2c-dev/ to see what number corresponds to which adapter.
Alternatively, you can run "i2cdetect -l" to obtain a formated list of all
Alternatively, you can run "i2cdetect -l" to obtain a formatted list of all
i2c adapters present on your system at a given time. i2cdetect is part of
the i2c-tools package.
......
......@@ -7,8 +7,8 @@ This is a proof-of-concept backend which acts like an EEPROM on the connected
I2C bus. The memory contents can be modified from userspace via this file
located in sysfs:
/sys/bus/i2c/devices/<device-direcory>/slave-eeprom
/sys/bus/i2c/devices/<device-directory>/slave-eeprom
As of 2015, Linux doesn't support poll on binary sysfs files, so there is no
notfication when another master changed the content.
notification when another master changed the content.
......@@ -440,7 +440,7 @@ MAINTAINERS ファイルにリストがありますので参照してくださ
てこの状態を変えようとしないように。人々はそのようなことは好みません。
今までのメールでのやりとりとその間のあなたの発言はそのまま残し、
"John Kernlehacker wrote ...:" の行をあなたのリプライの先頭行にして、
"John Kernelhacker wrote ...:" の行をあなたのリプライの先頭行にして、
メールの先頭でなく、各引用行の間にあなたの言いたいことを追加するべきで
す。
......
NOTE:
This is a version of Documentation/HOWTO translated into korean
This document is maintained by minchan Kim <minchan.kim@gmail.com>
This document is maintained by Minchan Kim <minchan@kernel.org>
If you find any difference between this document and the original file or
a problem with the translation, please contact the maintainer of this file.
......@@ -14,7 +14,7 @@ try to update the original English file first.
Documentation/HOWTO
한글 번역입니다.
역자: 김민찬 <minchan.kim@gmail.com>
역자: 김민찬 <minchan@kernel.org>
감수: 이제이미 <jamee.lee@samsung.com>
==================================
......
NOTE:
This is a version of Documentation/stable_api_nonsense.txt translated
into korean
This document is maintained by barrios <minchan.kim@gmail.com>
This document is maintained by Minchan Kim <minchan@kernel.org>
If you find any difference between this document and the original file or
a problem with the translation, please contact the maintainer of this file.
......@@ -15,7 +15,7 @@ try to update the original English file first.
Documentation/stable_api_nonsense.txt
의 한글 번역입니다.
역자: 김민찬 <minchan.kim@gmail.com>
역자: 김민찬 <minchan@kernel.org>
감수: 이제이미 <jamee.lee@samsung.com>
==================================
......
......@@ -73,7 +73,7 @@ To install selftests in an user specified location:
Contributing new tests
======================
In general, the rules for for selftests are
In general, the rules for selftests are
* Do as much as you can if you're not root;
......
......@@ -349,7 +349,7 @@ static ssize_t
sum_iovec_len(struct mic_copy_desc *copy)
{
ssize_t sum = 0;
int i;
unsigned int i;
for (i = 0; i < copy->iovcnt; i++)
sum += copy->iov[i].iov_len;
......@@ -372,7 +372,7 @@ static void
disp_iovec(struct mic_info *mic, struct mic_copy_desc *copy,
const char *s, int line)
{
int i;
unsigned int i;
for (i = 0; i < copy->iovcnt; i++)
mpsslog("%s %s %d copy->iov[%d] addr %p len 0x%zx\n",
......
......@@ -254,7 +254,7 @@ signature checking is all done within the kernel.
NON-VALID SIGNATURES AND UNSIGNED MODULES
=========================================
If CONFIG_MODULE_SIG_FORCE is enabled or enforcemodulesig=1 is supplied on
If CONFIG_MODULE_SIG_FORCE is enabled or module.sig_enforce=1 is supplied on
the kernel command line, the kernel will only load validly signed modules
for which it has a public key. Otherwise, it will also load modules that are
unsigned. Any module for which the kernel has a key, but which proves to have
......
......@@ -74,7 +74,7 @@ static void rdtsctask(void)
}
int main(int argc, char **argv)
int main(void)
{
int n_tasks = 100, i;
......
......@@ -78,7 +78,7 @@ static void task(void)
}
int main(int argc, char **argv)
int main(void)
{
int n_tasks = 100, i;
......
......@@ -57,7 +57,7 @@ static void sigsegv_cb(int sig)
printf("rdtsc() == ");
}
int main(int argc, char **argv)
int main(void)
{
int tsc_val = 0;
......
......@@ -160,7 +160,8 @@ int main(int argc, char *argv[])
char *progname;
int i, c, cnt, fd;
unsigned int i;
int c, cnt, fd;
char *device = DEVICE;
clockid_t clkid;
......
......@@ -49,7 +49,7 @@ struct hpet_command {
int
main(int argc, const char ** argv)
{
int i;
unsigned int i;
argc--;
argv++;
......
......@@ -6,8 +6,9 @@ communicating in English you can also ask the Chinese maintainer for
help. Contact the Chinese maintainer if this translation is outdated
or if there is a problem with the translation.
Maintainer: Will Deacon <will.deacon@arm.com>
Chinese maintainer: Fu Wei <wefu@redhat.com>
M: Will Deacon <will.deacon@arm.com>
zh_CN: Fu Wei <wefu@redhat.com>
C: 1926e54f115725a9248d0c4c65c22acaf94de4c4
---------------------------------------------------------------------
Documentation/arm64/booting.txt 的中文翻译
......@@ -15,12 +16,11 @@ Documentation/arm64/booting.txt 的中文翻译
交流有困难的话,也可以向中文版维护者求助。如果本翻译更新不及时或者翻
译存在问题,请联系中文版维护者。
本文翻译提交时的 Git 检出点为: bc465aa9d045feb0e13b4a8f32cc33c1943f62d6
英文版维护者: Will Deacon <will.deacon@arm.com>
中文版维护者: 傅炜 Fu Wei <wefu@redhat.com>
中文版翻译者: 傅炜 Fu Wei <wefu@redhat.com>
中文版校译者: 傅炜 Fu Wei <wefu@redhat.com>
本文翻译提交时的 Git 检出点为: 1926e54f115725a9248d0c4c65c22acaf94de4c4
以下为正文
---------------------------------------------------------------------
......@@ -33,9 +33,9 @@ Documentation/arm64/booting.txt 的中文翻译
本文档基于 Russell King 的 ARM 启动文档,且适用于所有公开发布的
AArch64 Linux 内核代码。
AArch64 异常模型由多个异常级别(EL0 - EL3)组成,对于 EL0 和 EL1
异常级有对应的安全和非安全模式。EL2 是系统管理级,且仅存在于
非安全模式下。EL3 是最高特权级,且仅存在于安全模式下。
AArch64 异常模型由多个异常级(EL0 - EL3)组成,对于 EL0 和 EL1 异常级
有对应的安全和非安全模式。EL2 是系统管理级,且仅存在于非安全模式下。
EL3 是最高特权级,且仅存在于安全模式下。
基于本文档的目的,我们将简单地使用‘引导装载程序’(‘boot loader’)
这个术语来定义在将控制权交给 Linux 内核前 CPU 上执行的所有软件。
......@@ -56,9 +56,9 @@ AArch64 异常模型由多个异常级别(EL0 - EL3)组成,对于 EL0 和
必要性: 强制
引导装载程序应该找到并初始化系统中所有内核用于保持系统变量数据的 RAM。
这个操作的执行是设备依赖的。(它可能使用内部算法来自动定位和计算所有
RAM,或可能使用对这个设备已知的 RAM 信息,还可能使用任何引导装载程序
设计者想到的匹配方法。)
这个操作的执行方式因设备而异。(它可能使用内部算法来自动定位和计算所有
RAM,或可能使用对这个设备已知的 RAM 信息,还可能是引导装载程序设计者
想到的任何合适的方法。)
2、设置设备树数据
......@@ -66,10 +66,12 @@ RAM,或可能使用对这个设备已知的 RAM 信息,还可能使用任何
必要性: 强制
设备树数据块(dtb)必须 8 字节对齐,并位于从内核映像起始算起第一个 512MB
内,且不得跨越 2MB 对齐边界。这使得内核可以通过初始页表中的单个节描述符来
映射此数据块
设备树数据块(dtb)必须 8 字节对齐,且大小不能超过 2MB。由于设备树
数据块将在使能缓存的情况下以 2MB 粒度被映射,故其不能被置于带任意
特定属性被映射的 2MB 区域内
注: v4.2 之前的版本同时要求设备树数据块被置于从内核映像以下
text_offset 字节处算起第一个 512MB 内。
3、解压内核映像
-------------
......@@ -78,7 +80,7 @@ RAM,或可能使用对这个设备已知的 RAM 信息,还可能使用任何
AArch64 内核当前没有提供自解压代码,因此如果使用了压缩内核映像文件
(比如 Image.gz),则需要通过引导装载程序(使用 gzip 等)来进行解压。
若引导装载程序没有实现这个需求,就要使用非压缩内核映像文件。
若引导装载程序没有实现这个功能,就要使用非压缩内核映像文件。
4、调用内核映像
......@@ -107,26 +109,36 @@ AArch64 内核当前没有提供自解压代码,因此如果使用了压缩内
- code0/code1 负责跳转到 stext.
- 当通过 EFI 启动时, 最初 code0/code1 被跳过。
res5 是到 PE 文件头的偏移,而 PE 文件头含有 EFI 的启动入口点 (efi_stub_entry)。
当 stub 代码完成了它的使命,它会跳转到 code0 继续正常的启动流程。
res5 是到 PE 文件头的偏移,而 PE 文件头含有 EFI 的启动入口点
(efi_stub_entry)。当 stub 代码完成了它的使命,它会跳转到 code0
继续正常的启动流程。
- v3.17 之前,未明确指定 text_offset 的字节序。此时,image_size 为零,
且 text_offset 依照内核字节序为 0x80000。
当 image_size 非零,text_offset 为小端模式且是有效值,应被引导加载程序使用。
当 image_size 为零,text_offset 可假定为 0x80000。
当 image_size 非零,text_offset 为小端模式且是有效值,应被引导加载
程序使用。当 image_size 为零,text_offset 可假定为 0x80000。
- flags 域 (v3.17 引入) 为 64 位小端模式,其编码如下:
位 0: 内核字节序。 1 表示大端模式,0 表示小端模式。
位 1-63: 保留。
- 当 image_size 为零时,引导装载程序应该试图在内核映像末尾之后尽可能多地保留空闲内存
供内核直接使用。对内存空间的需求量因所选定的内核特性而异, 且无实际限制。
内核映像必须被放置在靠近可用系统内存起始的 2MB 对齐为基址的 text_offset 字节处,并从那里被调用。
当前,对 Linux 来说在此基址以下的内存是无法使用的,因此强烈建议将系统内存的起始作为这个基址。
从映像起始地址算起,最少必须为内核释放出 image_size 字节的空间。
任何提供给内核的内存(甚至在 2MB 对齐的基地址之前),若未从内核中标记为保留
位 1-2: 内核页大小。
0 - 未指定。
1 - 4K
2 - 16K
3 - 64K
位 3-63: 保留。
- 当 image_size 为零时,引导装载程序应试图在内核映像末尾之后尽可能
多地保留空闲内存供内核直接使用。对内存空间的需求量因所选定的内核
特性而异, 并无实际限制。
内核映像必须被放置在靠近可用系统内存起始的 2MB 对齐为基址的
text_offset 字节处,并从该处被调用。当前,对 Linux 来说在此基址以下的
内存是无法使用的,因此强烈建议将系统内存的起始作为这个基址。2MB 对齐
基址和内核映像起始地址之间的区域对于内核来说没有特殊意义,且可能被
用于其他目的。
从映像起始地址算起,最少必须准备 image_size 字节的空闲内存供内核使用。
任何提供给内核的内存(甚至在映像起始地址之前),若未从内核中标记为保留
(如在设备树(dtb)的 memreserve 区域),都将被认为对内核是可用。
在跳转入内核前,必须符合以下状态:
......@@ -147,13 +159,16 @@ AArch64 内核当前没有提供自解压代码,因此如果使用了压缩内
- 高速缓存、MMU
MMU 必须关闭。
指令缓存开启或关闭都可以
指令缓存开启或关闭皆可
已载入的内核映像的相应内存区必须被清理,以达到缓存一致性点(PoC)。
当存在系统缓存或其他使能缓存的一致性主控器时,通常需使用虚拟地址维护其缓存,而非 set/way 操作。
当存在系统缓存或其他使能缓存的一致性主控器时,通常需使用虚拟地址
维护其缓存,而非 set/way 操作。
遵从通过虚拟地址操作维护构架缓存的系统缓存必须被配置,并可以被使能。
而不通过虚拟地址操作维护构架缓存的系统缓存(不推荐),必须被配置且禁用。
而不通过虚拟地址操作维护构架缓存的系统缓存(不推荐),必须被配置且
禁用。
*译者注:对于 PoC 以及缓存相关内容,请参考 ARMv8 构架参考手册 ARM DDI 0487A
*译者注:对于 PoC 以及缓存相关内容,请参考 ARMv8 构架参考手册
ARM DDI 0487A
- 架构计时器
CNTFRQ 必须设定为计时器的频率,且 CNTVOFF 必须设定为对所有 CPU
......@@ -169,13 +184,21 @@ AArch64 内核当前没有提供自解压代码,因此如果使用了压缩内
在进入内核映像的异常级中,所有构架中可写的系统寄存器必须通过软件
在一个更高的异常级别下初始化,以防止在 未知 状态下运行。
对于拥有 GICv3 中断控制器的系统:
- 若当前在 EL3
对于拥有 GICv3 中断控制器并以 v3 模式运行的系统:
- 如果 EL3 存在
ICC_SRE_EL3.Enable (位 3) 必须初始化为 0b1。
ICC_SRE_EL3.SRE (位 0) 必须初始化为 0b1。
- 若内核运行在 EL1:
ICC_SRE_EL2.Enable (位 3) 必须初始化为 0b1。
ICC_SRE_EL2.SRE (位 0) 必须初始化为 0b1。
- 设备树(DT)或 ACPI 表必须描述一个 GICv3 中断控制器。
对于拥有 GICv3 中断控制器并以兼容(v2)模式运行的系统:
- 如果 EL3 存在:
ICC_SRE_EL3.SRE (位 0) 必须初始化为 0b0。
- 若内核运行在 EL1:
ICC_SRE_EL2.SRE (位 0) 必须初始化为 0b0。
- 设备树(DT)或 ACPI 表必须描述一个 GICv2 中断控制器。
以上对于 CPU 模式、高速缓存、MMU、架构计时器、一致性、系统寄存器的
必要条件描述适用于所有 CPU。所有 CPU 必须在同一异常级别跳入内核。
......
Chinese translated version of Documentation/arm64/silicon-errata.txt
If you have any comment or update to the content, please contact the
original document maintainer directly. However, if you have a problem
communicating in English you can also ask the Chinese maintainer for
help. Contact the Chinese maintainer if this translation is outdated
or if there is a problem with the translation.
M: Will Deacon <will.deacon@arm.com>
zh_CN: Fu Wei <wefu@redhat.com>
C: 1926e54f115725a9248d0c4c65c22acaf94de4c4
---------------------------------------------------------------------
Documentation/arm64/silicon-errata.txt 的中文翻译
如果想评论或更新本文的内容,请直接联系原文档的维护者。如果你使用英文
交流有困难的话,也可以向中文版维护者求助。如果本翻译更新不及时或者翻
译存在问题,请联系中文版维护者。
英文版维护者: Will Deacon <will.deacon@arm.com>
中文版维护者: 傅炜 Fu Wei <wefu@redhat.com>
中文版翻译者: 傅炜 Fu Wei <wefu@redhat.com>
中文版校译者: 傅炜 Fu Wei <wefu@redhat.com>
本文翻译提交时的 Git 检出点为: 1926e54f115725a9248d0c4c65c22acaf94de4c4
以下为正文
---------------------------------------------------------------------
芯片勘误和软件补救措施
==================
作者: Will Deacon <will.deacon@arm.com>
日期: 2015年11月27日
一个不幸的现实:硬件经常带有一些所谓的“瑕疵(errata)”,导致其在
某些特定情况下会违背构架定义的行为。就基于 ARM 的硬件而言,这些瑕疵
大体可分为以下几类:
A 类:无可行补救措施的严重缺陷。
B 类:有可接受的补救措施的重大或严重缺陷。
C 类:在正常操作中不会显现的小瑕疵。
更多资讯,请在 infocenter.arm.com (需注册)中查阅“软件开发者勘误
笔记”(“Software Developers Errata Notice”)文档。
对于 Linux 而言,B 类缺陷可能需要操作系统的某些特别处理。例如,避免
一个特殊的代码序列,或是以一种特定的方式配置处理器。在某种不太常见的
情况下,为将 A 类缺陷当作 C 类处理,可能需要用类似的手段。这些手段被
统称为“软件补救措施”,且仅在少数情况需要(例如,那些需要一个运行在
非安全异常级的补救措施 *并且* 能被 Linux 触发的情况)。
对于尚在讨论中的可能对未受瑕疵影响的系统产生干扰的软件补救措施,有一个
相应的内核配置(Kconfig)选项被加在 “内核特性(Kernel Features)”->
“基于可选方法框架的 ARM 瑕疵补救措施(ARM errata workarounds via
the alternatives framework)"。这些选项被默认开启,若探测到受影响的CPU,
补丁将在运行时被使用。至于对系统运行影响较小的补救措施,内核配置选项
并不存在,且代码以某种规避瑕疵的方式被构造(带注释为宜)。
这种做法对于在任意内核源代码树中准确地判断出哪个瑕疵已被软件方法所补救
稍微有点麻烦,所以在 Linux 内核中此文件作为软件补救措施的注册表,
并将在新的软件补救措施被提交和向后移植(backported)到稳定内核时被更新。
| 实现者 | 受影响的组件 | 勘误编号 | 内核配置 |
+----------------+-----------------+-----------------+-------------------------+
| ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 |
| ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 |
| ARM | Cortex-A53 | #824069 | ARM64_ERRATUM_824069 |
| ARM | Cortex-A53 | #819472 | ARM64_ERRATUM_819472 |
| ARM | Cortex-A53 | #845719 | ARM64_ERRATUM_845719 |
| ARM | Cortex-A53 | #843419 | ARM64_ERRATUM_843419 |
| ARM | Cortex-A57 | #832075 | ARM64_ERRATUM_832075 |
| ARM | Cortex-A57 | #852523 | N/A |
| ARM | Cortex-A57 | #834220 | ARM64_ERRATUM_834220 |
| | | | |
| Cavium | ThunderX ITS | #22375, #24313 | CAVIUM_ERRATUM_22375 |
| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 |
......@@ -59,7 +59,7 @@ DOCUMENTATION:
INSTALLING the kernel source:
- If you install the full sources, put the kernel tarball in a
directory where you have permissions (eg. your home directory) and
directory where you have permissions (e.g. your home directory) and
unpack it:
xz -cd linux-4.X.tar.xz | tar xvf -
......@@ -125,7 +125,7 @@ BUILD directory for the kernel:
When compiling the kernel, all output files will per default be
stored together with the kernel source code.
Using the option "make O=output/dir" allow you to specify an alternate
Using the option "make O=output/dir" allows you to specify an alternate
place for the output files (including .config).
Example:
......@@ -159,9 +159,9 @@ CONFIGURING the kernel:
"make nconfig" Enhanced text based color menus.
"make xconfig" X windows (Qt) based configuration tool.
"make xconfig" Qt based configuration tool.
"make gconfig" X windows (GTK+) based configuration tool.
"make gconfig" GTK+ based configuration tool.
"make oldconfig" Default all questions based on the contents of
your existing ./.config file and asking about
......@@ -268,8 +268,8 @@ COMPILING the kernel:
Normally, the kernel build system runs in a fairly quiet mode (but not
totally silent). However, sometimes you or other kernel developers need
to see compile, link, or other commands exactly as they are executed.
For this, use "verbose" build mode. This is done by inserting
"V=1" in the "make" command. E.g.:
For this, use "verbose" build mode. This is done by passing
"V=1" to the "make" command, e.g.
make V=1 all
......@@ -300,7 +300,7 @@ COMPILING the kernel:
kernel image file is usually /vmlinuz, /boot/vmlinuz, /bzImage or
/boot/bzImage. To use the new kernel, save a copy of the old image
and copy the new image over the old one. Then, you MUST RERUN LILO
to update the loading map!! If you don't, you won't be able to boot
to update the loading map! If you don't, you won't be able to boot
the new kernel image.
Reinstalling LILO is usually a matter of running /sbin/lilo.
......
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