From 881cb618706439a6fc7b40e643c92a0147cad782 Mon Sep 17 00:00:00 2001 From: qhwdw Date: Thu, 25 Oct 2018 12:09:19 +0800 Subject: [PATCH 1/4] =?UTF-8?q?=E8=A1=A5=E5=85=85=E4=BA=86=E4=B8=A2?= =?UTF-8?q?=E5=A4=B1=E7=9A=84=E5=9B=9B=E4=B8=AA=E6=AE=B5=E8=90=BD?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...ffeinated 6.828：Lab 2 Memory Management.md | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/translated/tech/20140114 Caffeinated 6.828：Lab 2 Memory Management.md b/translated/tech/20140114 Caffeinated 6.828：Lab 2 Memory Management.md index 0e2a348679..39b20a33f0 100644 --- a/translated/tech/20140114 Caffeinated 6.828：Lab 2 Memory Management.md +++ b/translated/tech/20140114 Caffeinated 6.828：Lab 2 Memory Management.md @@ -12,7 +12,7 @@ 在本实验及后面的实验中，你将逐步构建你的内核。我们将会为你提供一些附加的资源。使用 Git 去获取这些资源、提交自实验 1 以来的改变（如有需要的话）、获取课程仓库的最新版本、以及在我们的实验 2 （origin/lab2）的基础上创建一个称为 lab2 的本地分支： -``` +```c athena% cd ~/6.828/lab athena% add git athena% git pull @@ -23,9 +23,11 @@ Switched to a new branch "lab2" athena% ``` +上面的 `git checkout -b` 命令其实做了两件事情：首先它创建了一个本地分支 `lab2`，它跟踪给我们提供课程内容的远程分支 `origin/lab2` ，第二件事情是，它更改的你的 `lab` 目录的内容反映到 `lab2` 分支上存储的文件中。Git 允许你在已存在的两个分支之间使用 `git checkout *branch-name*` 命令去切换，但是在你切换到另一个分支之前，你应该去提交那个分支上你做的任何出色的变更。 + 现在，你需要将你在 lab1 分支中的改变合并到 lab2 分支中，命令如下： -``` +```c athena% git merge lab1 Merge made by recursive. kern/kdebug.c | 11 +++++++++-- @@ -35,6 +37,8 @@ Merge made by recursive. athena% ``` +在一些案例中，Git 或许并不能找到如何将你的更改与新的实验任务合并（例如，你在第二个实验任务中变更了一些代码的修改）。在那种情况下，你使用 git 命令去合并，它会告诉你哪个文件发生了冲突，你必须首先去解决冲突（通过编辑冲突的文件），然后使用 `git commit -a` 去重新提交文件。 + 实验 2 包含如下的新源代码，后面你将遍历它们： - inc/memlayout.h @@ -53,13 +57,15 @@ athena% 在你准备进行实验和写代码之前，先添加你的 `answers-lab2.txt` 文件到 Git 仓库，提交你的改变然后去运行 `make handin`。 -``` +```c athena% git add answers-lab2.txt athena% git commit -am "my answer to lab2" [lab2 a823de9] my answer to lab2 4 files changed, 87 insertions(+), 10 deletions(-) athena% make handin ``` +正如前面所说的，我们将使用一个评级程序来分级你的解决方案，你可以在 `lab` 目录下运行 `make grade`，使用评级程序来测试你的内核。为了完成你的实验，你可以改变任何你需要的内核源代码和头文件。但毫无疑问的是，你不能以任何形式去改变或破坏评级代码。 + ### 第 1 部分：物理页面管理 操作系统必须跟踪物理内存页是否使用的状态。JOS 以页为最小粒度来管理 PC 的物理内存，以便于它使用 MMU 去映射和保护每个已分配的内存片段。 @@ -98,6 +104,8 @@ athena% make handin ![屏幕快照 2018-09-04 11.22.20](https://ws1.sinaimg.cn/large/0069RVTdly1fuxgrc398jj30gx04bgm1.jpg) +一个 C 指针是虚拟地址的“偏移量”部分。在 `boot/boot.S` 中我们安装了一个全局描述符表（GDT），它通过设置所有的段基址为 0，并且限制为 `0xffffffff` 来有效地禁用段转换。因此“段选择器”并不会生效，而线性地址总是等于虚拟地址的偏移量。在实验 3 中，为了设置权限级别，我们将与段有更多的交互。但是对于内存转换，我们将在整个 JOS 实验中忽略段，只专注于页转换。 + 回顾实验 1 中的第 3 部分，我们安装了一个简单的页表，这样内核就可以在 0xf0100000 链接的地址上运行，尽管它实际上是加载在 0x00100000 处的 ROM BIOS 的物理内存上。这个页表仅映射了 4MB 的内存。在实验中，你将要为 JOS 去设置虚拟内存布局，我们将从虚拟地址 0xf0000000 处开始扩展它，首先将物理内存扩展到 256MB，并映射许多其它区域的虚拟内存。 > 练习 3 @@ -165,9 +173,9 @@ JOS 分割处理器的 32 位线性地址空间为两部分：用户环境（进 你可以在 `inc/memlayout.h` 中找到一个图表，它有助于你去理解 JOS 内存布局，这在本实验和后面的实验中都会用到。 -### 权限和缺页隔离 +### 权限和故障隔离 -由于内核和用户的内存都存在于它们各自环境的地址空间中，因此我们需要在 x86 的页表中使用权限位去允许用户代码只能访问用户所属地址空间的部分。否则的话，用户代码中的 bug 可能会覆写内核数据，导致系统崩溃或者发生各种莫名其妙的的故障；用户代码也可能会偷窥其它环境的私有数据。 +由于内核和用户的内存都存在于它们各自环境的地址空间中，因此我们需要在 x86 的页表中使用权限位去允许用户代码只能访问用户所属地址空间的部分。否则，用户代码中的 bug 可能会覆写内核数据，导致系统崩溃或者发生各种莫名其妙的的故障；用户代码也可能会偷窥其它环境的私有数据。 对于 ULIM 以上部分的内存，用户环境没有任何权限，只有内核才可以读取和写入这部分内存。对于 [UTOP,ULIM] 地址范围，内核和用户都有相同的权限：它们可以读取但不能写入这个地址范围。这个地址范围是用于向用户环境暴露某些只读的内核数据结构。最后，低于 UTOP 的地址空间是为用户环境所使用的；用户环境将为访问这些内核设置权限。 From 2979c097d4c94ca44f222d749dea788c49cbee29 Mon Sep 17 00:00:00 2001 From: dianbanjiu Date: Thu, 25 Oct 2018 13:48:29 +0800 Subject: [PATCH 2/4] translating --- .../20181019 How to use Pandoc to produce a research paper.md | 1 + 1 file changed, 1 insertion(+) diff --git a/sources/tech/20181019 How to use Pandoc to produce a research paper.md b/sources/tech/20181019 How to use Pandoc to produce a research paper.md index 50993cbf9f..70941130cb 100644 --- a/sources/tech/20181019 How to use Pandoc to produce a research paper.md +++ b/sources/tech/20181019 How to use Pandoc to produce a research paper.md @@ -1,3 +1,4 @@ +translating by dianbanjiu How to use Pandoc to produce a research paper ====== Learn how to manage section references, figures, tables, and more in Markdown. From 37125e1c5aaba762c4349eee6a0136fc7430b651 Mon Sep 17 00:00:00 2001 From: "Xingyu.Wang" Date: Thu, 25 Oct 2018 14:37:50 +0800 Subject: [PATCH 3/4] PRF:20180830 6 places to host your git repository.md @dianbanjiu --- ...30 6 places to host your git repository.md | 26 +++++++++---------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/translated/tech/20180830 6 places to host your git repository.md b/translated/tech/20180830 6 places to host your git repository.md index 0d1bc8b98f..211e9972e9 100644 --- a/translated/tech/20180830 6 places to host your git repository.md +++ b/translated/tech/20180830 6 places to host your git repository.md @@ -1,41 +1,41 @@ -6 个托管你 git 仓库的地方 +6 个托管 git 仓库的地方 ====== +> GitHub 被收购导致一些用户去寻找这个流行的代码仓库的替代品。这里有一些你可以考虑一下。 ![](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/house_home_colors_live_building.jpg?itok=HLpsIfIL) -也许你是少数一些没有注意到的人之一就在几周前，[微软收购了 GitHub][1]。两家公司达成了共识。微软在近些年已经变成了开源的有力支持者，GitHub 从成立起，就已经成为了许多开源项目的实际代码库。 +也许你是少数一些没有注意到的人之一，就在之前，[微软收购了 GitHub][1]。两家公司达成了共识。微软在近些年已经变成了开源的有力支持者，而 GitHub 从成立起，就已经成为了大量的开源项目的实际代码库。 -然而，最近的购买可能会带给你一些烦躁。毕竟公司的收购让你意识到了你的开源代码放在了一个商业平台上。可能你现在还没准备好迁移到其他的平台上去，但是至少这可以给你提供一些可选项。让我们找找网上现在都有哪些可用的平台。 +然而，最近发生的这次收购可能会带给你一些苦恼。毕竟公司的收购让你意识到了你的开源代码放在了一个商业平台上。可能你现在还没准备好迁移到其他的平台上去，但是至少这可以给你提供一些可选项。让我们找找网上现在都有哪些可用的平台。 ### 选择之一： GitHub -严格来说，这是一个合格的选项。[GitHub][2] 历史上没有什么糟糕的失败，而且微软最近也确实发展了不少开源项目。把你的项目继续放在 GitHub 上，继续保持观望没有什么不可以。它现在依然是最大的软件开发的网络社区,同时还有许多对于问题追踪、代码复查、持续集成、通用的代码管理很有用的工具。而且它还是基于 Git 的，Git 是每个人都喜欢的开源版本控制系统。你的代码还是你的代码。 +严格来说，这是一个合格的选项。[GitHub][2] 历史上没有什么失信的地方，而且微软后来也一直笑对开源。把你的项目继续放在 GitHub 上，保持观望没有什么不可以。它现在依然是最大的软件开发的网络社区，同时还有许多对于问题追踪、代码审查、持续集成、通用的代码管理等很有用的工具。而且它还是基于 Git 的，这是每个人都喜欢的开源版本控制系统。你的代码还是你的代码。如果没有出现什么问题，那保持原状是没错的。 ### 选择之二： GitLab -[GitLab][3] 是代码库平台主要的竞争者。它是完全开源的。你可以像在 GitHhub 一样把你的代码托管在 GitLab，但你也可以选择在你自己的服务器上自行托管你自己的 GitLab 实例，并完全控制谁可以访问那里的所有内容以及如何访问、管理。 GitLab 与 GitHub 功能几乎相同，有些人甚至可能会说它的持续集成和测试工具更优越。尽管 GitLab 上的开发者社区肯定比 GitHub 上的开发者社区要小，但它仍然没有什么可以被指责的。你可能会在那里的人群中找到更多志同道合的开发者。 +[GitLab][3] 是考虑替代代码库平台时的主要竞争者。它是完全开源的。你可以像在 GitHub 一样把你的代码托管在 GitLab，但你也可以选择在你自己的服务器上自行托管自己的 GitLab 实例，并完全控制谁可以访问那里的所有内容以及如何访问和管理。GitLab 与 GitHub 功能几乎相同，有些人甚至可能会说它的持续集成和测试工具更优越。尽管 GitLab 上的开发者社区肯定比 GitHub 上的开发者社区要小，但这并没有什么。你可能会在那里的人群中找到更多志同道合的开发者。 ### 选择之三： Bitbucket -[Bitbucket][4] 已经存在很多年了。在某些方面，它可以作为 GitHub 未来的一面镜子。 Bitbucket 八年前被一家大公司（Atlassian）收购，并且已经经历了一些转换过程。 它仍然是一个像 GitHub 这样的商业平台，但它远不是一个创业公司，而且从组织上说它的基础相当稳定。 Bitbucket 分享了 GitHub 和 GitLab 上的大部分功能，以及它自己的一些新功能，如对 [Mercurial][5] 存储库的本机支持。 +[Bitbucket][4] 已经存在很多年了。在某些方面，它可以作为 GitHub 未来的一面镜子。Bitbucket 八年前被一家大公司（Atlassian）收购，并且已经经历了一些变化。它仍然是一个像 GitHub 这样的商业平台，但它远不是一个创业公司，而且从组织上说它的基础相当稳定。Bitbucket 具有 GitHub 和 GitLab 上的大部分功能，以及它自己的一些新功能，如对 [Mercurial][5] 仓库的原生支持。 ### 选择之四： SourceForge -[SourceForge][6] 是开源代码库的鼻祖。如果你曾经有一个开源项目，Sourceforge 是一个托管你的代码和向他人分享你的发行版的地方。迁移到 Git 进行版本控制需要一段时间，它有自己的商业收购和重新组构的事件，以及一些开源项目的一些不幸的捆绑决策。也就是说，SourceForge 从那时起似乎已经恢复，该网站仍然是一个有着不少开源项目的地方。 然而，很多人仍然感到有点受伤，而且有些人并不是各种尝试通过平台货币化的忠实粉丝，所以一定要睁大眼睛。 +[SourceForge][6] 是开源代码库的鼻祖。如果你曾经有一个开源项目，Sourceforge 就是那个托管你的代码并向其他人分享你的发布版本的地方。它迁移到 Git 版本控制用了一段时间，它有一些商业收购和再次收购的历史，以及一些对某些开源项目糟糕的捆绑决策。也就是说，SourceForge 从那时起似乎已经恢复，该网站仍然是一个有着不少开源项目的地方。然而，很多人仍然感到有点受伤，而且有些人并不是很支持它的平台货币化的各种尝试，所以一定要睁大眼睛。 ### 选择之五： 自己管理 -如果你想自己掌握自己项目的命运（除了你自己没人可以责备你），然后一切都由自己来做对你来说可能是最佳的选择。无论对于大项目还是小项目。Git 是开源的，所以自己托管也很容易。如果你问题追踪和代码审查，你可以运行一个 GitLab 或者 [Phabricator][7] 的实例。对于持续集成，你可以设置自己的 [Jenkins][8] 自动化服务的实例。是的，你需要对自己的基础架构开销和相关的安全要求负责。但是，这个设置过程并不是很困难。所以如果你不想自己的代码被其他人的平台所吞没，这就是一种很好的方法。 +如果你想自己掌握自己项目的命运（除了你自己没人可以指责你），那么一切都由自己来做可能对你来说是最佳的选择。无论对于大项目还是小项目，都是好的选择。Git 是开源的，所以自己托管也很容易。如果你想要问题追踪和代码审查功能，你可以运行一个 GitLab 或者 [Phabricator][7] 的实例。对于持续集成，你可以设置自己的 [Jenkins][8] 自动化服务实例。是的，你需要对自己的基础架构开销和相关的安全要求负责。但是，这个设置过程并不是很困难。所以如果你不想自己的代码被其他人的平台所吞没，这就是一种很好的方法。 ### 选择之六：以上全部 -以下是所有这些的美妙之处：尽管这些平台上有一些专有的选项，但它们仍然建立在坚实的开源技术之上。 而且不仅仅是开源，而是明确设计为分布在大型网络（如互联网）上的多个节点上。 你不需要只使用一个。 你可以使用一对......或者全部。 使用 GitLab 将你自己的设置作为保证的基础，并在 GitHub 和 Bitbucket 上安装克隆存储库，以进行问题跟踪和持续集成。 将你的主代码库保留在 GitHub 上，但是为了你自己的想法，可以在 GitLab 上安装“备份”克隆。 +以下是所有这些的美妙之处：尽管这些平台上有一些专有的选项，但它们仍然建立在坚实的开源技术之上。而且不仅仅是开源，而是明确设计为分布在大型网络（如互联网）上的多个节点上。你不需要只使用一个。你可以使用一对……或者全部。使用 GitLab 将你自己的设施作为保证的基础，并在 GitHub 和 Bitbucket 上安装克隆存储库，以进行问题跟踪和持续集成。将你的主代码库保留在 GitHub 上，但是出于你自己的考虑，可以在 GitLab 上安装“备份”克隆。 -关键在于你的选择是什么。我们能有这么多选择，都是得益于那些非常有用的项目上的开源协议。未来一片光明。 +关键在于你可以选择。我们能有这么多选择，都是得益于那些非常有用而强大的项目之上的开源许可证。未来一片光明。 -当然，在这个列表中我肯定忽略了一些开源平台。你是否使用了很多的平台？哪个是你最喜欢的？你都可以在这里说出来！ +当然，在这个列表中我肯定忽略了一些开源平台。方便的话请补充给我们。你是否使用了多个平台？哪个是你最喜欢的？你都可以在这里说出来！ -：） -------------------------------------------------------------------------------- @@ -44,7 +44,7 @@ via: https://opensource.com/article/18/8/github-alternatives 作者：[Jason van Gumster][a] 选题：[lujun9972](https://github.com/lujun9972) 译者：[dianbanjiu](https://github.com/dianbanjiu) -校对：[校对者ID](https://github.com/校对者ID) +校对：[wxy](https://github.com/wxy) 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 From 1364dc08a06c05879e2d7d43a94e1cfa8757247f Mon Sep 17 00:00:00 2001 From: "Xingyu.Wang" Date: Thu, 25 Oct 2018 14:38:13 +0800 Subject: [PATCH 4/4] PUB:20180830 6 places to host your git repository.md @dianbanjiu https://linux.cn/article-10153-1.html --- .../20180830 6 places to host your git repository.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename {translated/tech => published}/20180830 6 places to host your git repository.md (100%) diff --git a/translated/tech/20180830 6 places to host your git repository.md b/published/20180830 6 places to host your git repository.md similarity index 100% rename from translated/tech/20180830 6 places to host your git repository.md rename to published/20180830 6 places to host your git repository.md