Another relatively boring cycle for the docs tree: typo fixes, translation
updates, etc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJW6IqKAAoJEI3ONVYwIuV6zawP/2NG5Rh9a/6B9YbtVsXZrWD+ wCK80j+tbH9yAba54GjdJ2nvMKSYpC62ti4sPwtdSllvd0/e2ZnS4ZLa9sSoMDsH GK10mYhUcosDfeNCadT66Wl9o8ICu2QqNvGUtjI1331dcjAKBxLjJfaVQ9nddcdP Ksr8+ATr1rQE8YfxdprOnaX06C0FKqaQfRWdBl4FNDh6pb6eeXWnP56A+m3zi7e8 R2uJGlHwxq3qS27JkQDwiWFb7FVPt1H6bfM9DcgiGfItfgoosW1cExxND4MoqEZT 8ATE1H4Zbn6QOkq88Wo4vDn3gDIsgy7D7rS69juFNzCajxIOaN8NfPusGFmTCpQU cuh6XDYKS2n05RU0tuLB9NxTd+1b50COVHD//dEhjvpF+Z7Ku6yM2LrhTYYvoAsm XFYUUrJ8i09D0hllRA8WGE+AYGLvyFV9AE1mJQPepx+9TjBluKuqIoig03kEWfof 3xXhigFy+WttLQZiqten3YMVSo4xQRNq7FgqZ20dPMF1Exnj1wkwDFrE3SBB3Xcv 3eN953O12JzL7ja+9/OPMKZt8xs/tzLAScMP4R/nXGG050aecRH/xFFrOlzPDdyQ oshon67cMGi5qJdHaOkALqwz89euXv/AMHxGixu1M0zJG81WQm1u6vi9lY7b8Y3q ojA8vgsG3AprS9nmxqVh =wBKa -----END PGP SIGNATURE----- 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"
This commit is contained in:
Linus Torvalds
commit
37aa7319cd
28 changed files with 176 additions and 83 deletions
|
|
@ -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
|
||||
|
|
@ -187,7 +187,7 @@ apply a patch.
|
|||
If you do not know where you want to start, but you want to look for
|
||||
some task to start doing to join into the kernel development community,
|
||||
go to the Linux Kernel Janitor's project:
|
||||
http://kernelnewbies.org/KernelJanitors
|
||||
http://kernelnewbies.org/KernelJanitors
|
||||
It is a great place to start. It describes a list of relatively simple
|
||||
problems that need to be cleaned up and fixed within the Linux kernel
|
||||
source tree. Working with the developers in charge of this project, you
|
||||
|
|
@ -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 ...:" の行をあなたのリプライの先頭行にして、
|
||||
メールの先頭でなく、各引用行の間にあなたの言いたいことを追加するべきで
|
||||
す。
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
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>
|
||||
==================================
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
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、调用内核映像
|
||||
|
|
@ -97,7 +99,7 @@ AArch64 内核当前没有提供自解压代码，因此如果使用了压缩内
|
|||
u64 res3 = 0; /* 保留 */
|
||||
u64 res4 = 0; /* 保留 */
|
||||
u32 magic = 0x644d5241; /* 魔数, 小端, "ARM\x64" */
|
||||
u32 res5; /* 保留 （用于 PE COFF 偏移） */
|
||||
u32 res5; /* 保留 （用于 PE COFF 偏移） */
|
||||
|
||||
|
||||
映像头注释：
|
||||
|
|
@ -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: 保留。
|
||||
位 1-2: 内核页大小。
|
||||
0 - 未指定。
|
||||
1 - 4K
|
||||
2 - 16K
|
||||
3 - 64K
|
||||
位 3-63: 保留。
|
||||
|
||||
- 当 image_size 为零时，引导装载程序应该试图在内核映像末尾之后尽可能多地保留空闲内存
|
||||
供内核直接使用。对内存空间的需求量因所选定的内核特性而异, 且无实际限制。
|
||||
- 当 image_size 为零时，引导装载程序应试图在内核映像末尾之后尽可能
|
||||
多地保留空闲内存供内核直接使用。对内存空间的需求量因所选定的内核
|
||||
特性而异, 并无实际限制。
|
||||
|
||||
内核映像必须被放置在靠近可用系统内存起始的 2MB 对齐为基址的 text_offset 字节处，并从那里被调用。
|
||||
当前，对 Linux 来说在此基址以下的内存是无法使用的，因此强烈建议将系统内存的起始作为这个基址。
|
||||
从映像起始地址算起，最少必须为内核释放出 image_size 字节的空间。
|
||||
内核映像必须被放置在靠近可用系统内存起始的 2MB 对齐为基址的
|
||||
text_offset 字节处，并从该处被调用。当前，对 Linux 来说在此基址以下的
|
||||
内存是无法使用的，因此强烈建议将系统内存的起始作为这个基址。2MB 对齐
|
||||
基址和内核映像起始地址之间的区域对于内核来说没有特殊意义，且可能被
|
||||
用于其他目的。
|
||||
从映像起始地址算起，最少必须准备 image_size 字节的空闲内存供内核使用。
|
||||
|
||||
任何提供给内核的内存（甚至在 2MB 对齐的基地址之前），若未从内核中标记为保留
|
||||
任何提供给内核的内存（甚至在映像起始地址之前），若未从内核中标记为保留
|
||||
(如在设备树（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 必须在同一异常级别跳入内核。
|
||||
|
|
|
|||
74
Documentation/zh_CN/arm64/silicon-errata.txt
Normal file
74
Documentation/zh_CN/arm64/silicon-errata.txt
Normal file
|
|
@ -0,0 +1,74 @@
|
|||
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 |
|
||||
14
README
14
README
|
|
@ -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.
|
||||
|
|
|
|||
Loading…
Reference in a new issue