summaryrefslogtreecommitdiffstats
path: root/Documentation/zh_CN
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2016-05-19 18:07:25 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2016-05-19 18:07:25 -0700
commite9ad9b9bd3a3b95c89a29b2a197476e662db4233 (patch)
tree0b5e6c09953edc1a0bfab0b2aa964b80bceb5efd /Documentation/zh_CN
parent78975f23cba0cd195db01cdbd6eb48138a655890 (diff)
parent9f8036643dd9609b329aa1b89c9a95981e9ba62f (diff)
downloadlinux-e9ad9b9bd3a3b95c89a29b2a197476e662db4233.tar.bz2
Merge tag 'docs-for-linus' of git://git.lwn.net/linux
Pull Documentation updates from Jon Corbet: "A bit busier this time around. The most interesting thing (IMO) this time around is some beginning infrastructural work to allow documents to be written using restructured text. Maybe someday, in a galaxy far far away, we'll be able to eliminate the DocBook dependency and have a much better integrated set of kernel docs. Someday. Beyond that, there's a new document on security hardening from Kees, the movement of some sample code over to samples/, a number of improvements to the serial docs from Geert, and the usual collection of corrections, typo fixes, etc" * tag 'docs-for-linus' of git://git.lwn.net/linux: (55 commits) doc: self-protection: provide initial details serial: doc: Use port->state instead of info serial: doc: Always refer to tty_port->mutex Documentation: vm: Spelling s/paltform/platform/g Documentation/memcg: update kmem limit doc as codes behavior docproc: print a comment about autogeneration for rst output docproc: add support for reStructuredText format via --rst option docproc: abstract terminating lines at first space docproc: abstract docproc directive detection docproc: reduce unnecessary indentation docproc: add variables for subcommand and filename kernel-doc: use rst C domain directives and references for types kernel-doc: produce RestructuredText output kernel-doc: rewrite usage description, remove duplicated comments Doc: correct the location of sysrq.c Documentation: fix common spelling mistakes samples: v4l: from Documentation to samples directory samples: connector: from Documentation to samples directory Documentation: xillybus: fix spelling mistake Documentation: x86: fix spelling mistakes ...
Diffstat (limited to 'Documentation/zh_CN')
-rw-r--r--Documentation/zh_CN/HOWTO4
-rw-r--r--Documentation/zh_CN/arm64/booting.txt20
2 files changed, 13 insertions, 11 deletions
diff --git a/Documentation/zh_CN/HOWTO b/Documentation/zh_CN/HOWTO
index 54ea24ff63c7..f0613b92e0be 100644
--- a/Documentation/zh_CN/HOWTO
+++ b/Documentation/zh_CN/HOWTO
@@ -207,7 +207,7 @@ kernel.org网站的pub/linux/kernel/v2.6/目录下找到它。它的开发遵循
- 每当一个新版本的内核被发布,为期两周的集成窗口将被打开。在这段时间里
维护者可以向Linus提交大段的修改,通常这些修改已经被放到-mm内核中几个
星期了。提交大量修改的首选方式是使用git工具(内核的代码版本管理工具
- ,更多的信息可以在http://git.or.cz/获取),不过使用普通补丁也是可以
+ ,更多的信息可以在http://git-scm.com/获取),不过使用普通补丁也是可以
的。
- 两个星期以后-rc1版本内核发布。之后只有不包含可能影响整个内核稳定性的
新功能的补丁才可能被接受。请注意一个全新的驱动程序(或者文件系统)有
@@ -218,8 +218,6 @@ kernel.org网站的pub/linux/kernel/v2.6/目录下找到它。它的开发遵循
时,一个新的-rc版本就会被发布。计划是每周都发布新的-rc版本。
- 这个过程一直持续下去直到内核被认为达到足够稳定的状态,持续时间大概是
6个星期。
- - 以下地址跟踪了在每个-rc发布中发现的退步列表:
- http://kernelnewbies.org/known_regressions
关于内核发布,值得一提的是Andrew Morton在linux-kernel邮件列表中如是说:
“没有人知道新内核何时会被发布,因为发布是根据已知bug的情况来决定
diff --git a/Documentation/zh_CN/arm64/booting.txt b/Documentation/zh_CN/arm64/booting.txt
index 1145bf864082..c1dd968c5ee9 100644
--- a/Documentation/zh_CN/arm64/booting.txt
+++ b/Documentation/zh_CN/arm64/booting.txt
@@ -8,7 +8,7 @@ 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
+C: 55f058e7574c3615dea4615573a19bdb258696c6
---------------------------------------------------------------------
Documentation/arm64/booting.txt 的中文翻译
@@ -20,7 +20,7 @@ Documentation/arm64/booting.txt 的中文翻译
中文版维护者: 傅炜 Fu Wei <wefu@redhat.com>
中文版翻译者: 傅炜 Fu Wei <wefu@redhat.com>
中文版校译者: 傅炜 Fu Wei <wefu@redhat.com>
-本文翻译提交时的 Git 检出点为: 1926e54f115725a9248d0c4c65c22acaf94de4c4
+本文翻译提交时的 Git 检出点为: 55f058e7574c3615dea4615573a19bdb258696c6
以下为正文
---------------------------------------------------------------------
@@ -125,18 +125,22 @@ AArch64 内核当前没有提供自解压代码,因此如果使用了压缩内
1 - 4K
2 - 16K
3 - 64K
- 位 3-63: 保留。
+ 位 3: 内核物理位置
+ 0 - 2MB 对齐基址应尽量靠近内存起始处,因为
+ 其基址以下的内存无法通过线性映射访问
+ 1 - 2MB 对齐基址可以在物理内存的任意位置
+ 位 4-63: 保留。
- 当 image_size 为零时,引导装载程序应试图在内核映像末尾之后尽可能
多地保留空闲内存供内核直接使用。对内存空间的需求量因所选定的内核
特性而异, 并无实际限制。
-内核映像必须被放置在靠近可用系统内存起始的 2MB 对齐为基址的
-text_offset 字节处,并从该处被调用。当前,对 Linux 来说在此基址以下的
-内存是无法使用的,因此强烈建议将系统内存的起始作为这个基址。2MB 对齐
-基址和内核映像起始地址之间的区域对于内核来说没有特殊意义,且可能被
-用于其他目的。
+内核映像必须被放置在任意一个可用系统内存 2MB 对齐基址的 text_offset
+字节处,并从该处被调用。2MB 对齐基址和内核映像起始地址之间的区域对于
+内核来说没有特殊意义,且可能被用于其他目的。
从映像起始地址算起,最少必须准备 image_size 字节的空闲内存供内核使用。
+注: v4.6 之前的版本无法使用内核映像物理偏移以下的内存,所以当时建议
+将映像尽量放置在靠近系统内存起始的地方。
任何提供给内核的内存(甚至在映像起始地址之前),若未从内核中标记为保留
(如在设备树(dtb)的 memreserve 区域),都将被认为对内核是可用。