mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
Merge branch 'master' of https://github.com/LCTT/TranslateProject into new
This commit is contained in:
geekpi
commit
66d868c550
@ -1,28 +1,23 @@
|
||||
# 用 350 行代码从零开始，将 Lisp 编译成 JavaScript
|
||||
用 350 行代码从零开始，将 Lisp 编译成 JavaScript
|
||||
======
|
||||
|
||||
我们将会在本篇文章中看到从零开始实现的编译器，将简单的类 LISP 计算语言编译成 JavaScript。完整的源代码在 [这里][7].
|
||||
我们将会在本篇文章中看到从零开始实现的编译器，将简单的类 LISP 计算语言编译成 JavaScript。完整的源代码在 [这里][7]。
|
||||
|
||||
我们将会：
|
||||
|
||||
1. 自定义语言，并用它编写一个简单的程序
|
||||
|
||||
2. 实现一个简单的解析器组合器
|
||||
|
||||
3. 为该语言实现一个解析器
|
||||
|
||||
4. 为该语言实现一个美观的打印器
|
||||
|
||||
5. 为我们的需求定义 JavaScript 的一个子集
|
||||
|
||||
5. 为我们的用途定义 JavaScript 的一个子集
|
||||
6. 实现代码转译器，将代码转译成我们定义的 JavaScript 子集
|
||||
|
||||
7. 把所有东西整合在一起
|
||||
|
||||
开始吧！
|
||||
|
||||
### 1. 定义语言
|
||||
### 1、定义语言
|
||||
|
||||
lisps 最迷人的地方在于，它们的语法就是树状表示的，这就是这门语言很容易解析的原因。我们很快就能接触到它。但首先让我们把自己的语言定义好。关于我们语言的语法的范式（BNF）描述如下：
|
||||
Lisp 族语言最迷人的地方在于，它们的语法就是树状表示的，这就是这门语言很容易解析的原因。我们很快就能接触到它。但首先让我们把自己的语言定义好。关于我们语言的语法的范式（BNF）描述如下：
|
||||
|
||||
```
|
||||
program ::= expr
|
||||
@ -35,17 +30,17 @@ expr ::= <integer> | <name> | ([<expr>])
|
||||
|
||||
该语言中，我们保留一些内建的特殊形式，这样我们就能做一些更有意思的事情：
|
||||
|
||||
* let 表达式使我们可以在它的 body 环境中引入新的变量。语法如下：
|
||||
* `let` 表达式使我们可以在它的 `body` 环境中引入新的变量。语法如下：
|
||||
|
||||
```
|
||||
```
|
||||
let ::= (let ([<letarg>]) <body>)
|
||||
letargs ::= (<name> <expr>)
|
||||
body ::= <expr>
|
||||
```
|
||||
|
||||
* lambda 表达式：也就是匿名函数定义。语法如下：
|
||||
* `lambda` 表达式：也就是匿名函数定义。语法如下：
|
||||
|
||||
```
|
||||
```
|
||||
lambda ::= (lambda ([<name>]) <body>)
|
||||
```
|
||||
|
||||
@ -94,12 +89,11 @@ data Atom
|
||||
另一件你想做的事情可能是在语法中添加一些注释信息。比如定位：`Expr` 是来自哪个文件的，具体到这个文件的哪一行哪一列。你可以在后面的阶段中使用这一特性，打印出错误定位，即使它们不是处于解析阶段。
|
||||
|
||||
* _练习 1_：添加一个 `Program` 数据类型，可以按顺序包含多个 `Expr`
|
||||
|
||||
* _练习 2_：向语法树中添加一个定位注解。
|
||||
|
||||
### 2. 实现一个简单的解析器组合库
|
||||
### 2、实现一个简单的解析器组合库
|
||||
|
||||
我们要做的第一件事情是定义一个嵌入式领域专用语言（Embedded Domain Specific Language 或者 EDSL），我们会用它来定义我们的语言解析器。这常常被称为解析器组合库。我们做这件事完全是出于学习的目的，Haskell 里有很好的解析库，在实际构建软件或者进行实验时，你应该使用它们。[megaparsec][8] 就是这样的一个库。
|
||||
我们要做的第一件事情是定义一个<ruby>嵌入式领域专用语言<rt>Embedded Domain Specific Language</rt></ruby>（EDSL），我们会用它来定义我们的语言解析器。这常常被称为解析器组合库。我们做这件事完全是出于学习的目的，Haskell 里有很好的解析库，在实际构建软件或者进行实验时，你应该使用它们。[megaparsec][8] 就是这样的一个库。
|
||||
|
||||
首先我们来谈谈解析库的实现的思路。本质上，我们的解析器就是一个函数，接受一些输入，可能会读取输入的一些或全部内容，然后返回解析出来的值和无法解析的输入部分，或者在解析失败时抛出异常。我们把它写出来。
|
||||
|
||||
@ -114,7 +108,6 @@ data ParseError
|
||||
= ParseError ParseString Error
|
||||
|
||||
type Error = String
|
||||
|
||||
```
|
||||
|
||||
这里我们定义了三个主要的新类型。
|
||||
@ -124,9 +117,7 @@ type Error = String
|
||||
第二个，`ParseString` 是我们的输入或携带的状态。它有三个重要的部分：
|
||||
|
||||
* `Name`: 这是源的名字
|
||||
|
||||
* `(Int, Int)`: 这是源的当前位置
|
||||
|
||||
* `String`: 这是等待解析的字符串
|
||||
|
||||
第三个，`ParseError` 包含了解析器的当前状态和一个错误信息。
|
||||
@ -180,13 +171,11 @@ instance Monad Parser where
|
||||
Right (rs, rest) ->
|
||||
case f rs of
|
||||
Parser parser -> parser rest
|
||||
|
||||
```
|
||||
|
||||
接下来，让我们定义一种的方式，用于运行解析器和防止失败的助手函数：
|
||||
|
||||
```
|
||||
|
||||
runParser :: String -> String -> Parser a -> Either ParseError (a, ParseString)
|
||||
runParser name str (Parser parser) = parser $ ParseString name (0,0) str
|
||||
|
||||
@ -237,7 +226,6 @@ many parser = go []
|
||||
many1 :: Parser a -> Parser [a]
|
||||
many1 parser =
|
||||
(:) <$> parser <*> many parser
|
||||
|
||||
```
|
||||
|
||||
下面的这些解析器通过我们定义的组合器来实现一些特殊的解析器：
|
||||
@ -273,14 +261,13 @@ sepBy sep parser = do
|
||||
frst <- optional parser
|
||||
rest <- many (sep *> parser)
|
||||
pure $ maybe rest (:rest) frst
|
||||
|
||||
```
|
||||
|
||||
现在为该门语言定义解析器所需要的所有东西都有了。
|
||||
|
||||
* _练习_ ：实现一个 EOF（end of file/input，即文件或输入终止符）解析器组合器。
|
||||
* _练习_ ：实现一个 EOF（end of file/input，即文件或输入终止符）解析器组合器。
|
||||
|
||||
### 3. 为我们的语言实现解析器
|
||||
### 3、为我们的语言实现解析器
|
||||
|
||||
我们会用自顶而下的方法定义解析器。
|
||||
|
||||
@ -296,7 +283,6 @@ parseAtom = parseSymbol <|> parseInt
|
||||
|
||||
parseSymbol :: Parser Atom
|
||||
parseSymbol = fmap Symbol parseName
|
||||
|
||||
```
|
||||
|
||||
注意到这四个函数是在我们这门语言中属于高阶描述。这解释了为什么 Haskell 执行解析工作这么棒。在定义完高级部分后，我们还需要定义低级别的 `parseName` 和 `parseInt`。
|
||||
@ -311,7 +297,7 @@ parseName = do
|
||||
pure (c:cs)
|
||||
```
|
||||
|
||||
整数是一系列数字，数字前面可能有负号 ‘-’：
|
||||
整数是一系列数字，数字前面可能有负号 `-`：
|
||||
|
||||
```
|
||||
parseInt :: Parser Atom
|
||||
@ -333,12 +319,10 @@ runExprParser name str =
|
||||
```
|
||||
|
||||
* _练习 1_ ：为第一节中定义的 `Program` 类型编写一个解析器
|
||||
|
||||
* _练习 2_ ：用 Applicative 的形式重写 `parseName`
|
||||
|
||||
* _练习 3_ ：`parseInt` 可能出现溢出情况，找到处理它的方法，不要用 `read`。
|
||||
|
||||
### 4. 为这门语言实现一个更好看的输出器
|
||||
### 4、为这门语言实现一个更好看的输出器
|
||||
|
||||
我们还想做一件事，将我们的程序以源代码的形式打印出来。这对完善错误信息很有用。
|
||||
|
||||
@ -372,7 +356,7 @@ indent tabs e = concat (replicate tabs " ") ++ e
|
||||
|
||||
好，目前为止我们写了近 200 行代码，这些代码一般叫做编译器的前端。我们还要写大概 150 行代码，用来执行三个额外的任务：我们需要根据需求定义一个 JS 的子集，定义一个将我们的语言转译成这个子集的转译器，最后把所有东西整合在一起。开始吧。
|
||||
|
||||
### 5. 根据需求定义 JavaScript 的子集
|
||||
### 5、根据需求定义 JavaScript 的子集
|
||||
|
||||
首先，我们要定义将要使用的 JavaScript 的子集：
|
||||
|
||||
@ -411,10 +395,9 @@ printJSExpr doindent tabs = \case
|
||||
```
|
||||
|
||||
* _练习 1_ ：添加 `JSProgram` 类型，它可以包含多个 `JSExpr` ，然后创建一个叫做 `printJSExprProgram` 的函数来生成代码。
|
||||
|
||||
* _练习 2_ ：添加 `JSExpr` 的新类型：`JSIf`，并为其生成代码。
|
||||
|
||||
### 6. 实现到我们定义的 JavaScript 子集的代码转译器
|
||||
### 6、实现到我们定义的 JavaScript 子集的代码转译器
|
||||
|
||||
我们快做完了。这一节将会创建函数，将 `Expr` 转译成 `JSExpr`。
|
||||
|
||||
@ -437,7 +420,6 @@ translateList = \case
|
||||
f xs
|
||||
f:xs ->
|
||||
JSFunCall <$> translateToJS f <*> traverse translateToJS xs
|
||||
|
||||
```
|
||||
|
||||
`builtins` 是一系列要转译的特例，就像 `lambada` 和 `let`。每一种情况都可以获得一系列参数，验证它是否合乎语法规范，然后将其转译成等效的 `JSExpr`。
|
||||
@ -456,7 +438,6 @@ builtins =
|
||||
,("div", transBinOp "div" "/")
|
||||
,("print", transPrint)
|
||||
]
|
||||
|
||||
```
|
||||
|
||||
我们这种情况，会将内建的特殊形式当作特殊的、非第一类的进行对待，因此不可能将它们当作第一类函数。
|
||||
@ -480,10 +461,9 @@ transLambda = \case
|
||||
fromSymbol :: Expr -> Either String Name
|
||||
fromSymbol (ATOM (Symbol s)) = Right s
|
||||
fromSymbol e = Left $ "cannot bind value to non symbol type: " ++ show e
|
||||
|
||||
```
|
||||
|
||||
我们会将 let 转译成带有相关名字参数的函数定义，然后带上参数调用函数，因此会在这一作用域中引入变量：
|
||||
我们会将 `let` 转译成带有相关名字参数的函数定义，然后带上参数调用函数，因此会在这一作用域中引入变量：
|
||||
|
||||
```
|
||||
transLet :: [Expr] -> Either TransError JSExpr
|
||||
@ -522,35 +502,27 @@ transBinOp _ f list = foldl1 (JSBinOp f) <$> traverse translateToJS list
|
||||
transPrint :: [Expr] -> Either TransError JSExpr
|
||||
transPrint [expr] = JSFunCall (JSSymbol "console.log") . (:[]) <$> translateToJS expr
|
||||
transPrint xs = Left $ "Syntax error. print expected 1 arguments, got: " ++ show (length xs)
|
||||
|
||||
```
|
||||
|
||||
注意，如果我们将这些代码当作 `Expr` 的特例进行解析，那我们就可能会跳过语法验证。
|
||||
|
||||
* _练习 1_ ：将 `Program` 转译成 `JSProgram`
|
||||
|
||||
* _练习 2_ ：为 `if Expr Expr Expr` 添加一个特例，并将它转译成你在上一次练习中实现的 `JSIf` 条件语句。
|
||||
|
||||
### 7. 把所有东西整合到一起
|
||||
### 7、把所有东西整合到一起
|
||||
|
||||
最终，我们将会把所有东西整合到一起。我们会：
|
||||
|
||||
1. 读取文件
|
||||
|
||||
2. 将文件解析成 `Expr`
|
||||
|
||||
3. 将文件转译成 `JSExpr`
|
||||
|
||||
4. 将 JavaScript 代码发送到标准输出流
|
||||
|
||||
我们还会启用一些用于测试的标志位：
|
||||
|
||||
* `--e` 将进行解析并打印出表达式的抽象表示（`Expr`）
|
||||
|
||||
* `--pp` 将进行解析，美化输出
|
||||
|
||||
* `--jse` 将进行解析、转译、并打印出生成的 JS 表达式（`JSExpr`）的抽象表示
|
||||
|
||||
* `--ppc` 将进行解析，美化输出并进行编译
|
||||
|
||||
```
|
||||
@ -616,10 +588,10 @@ undefined
|
||||
|
||||
via: https://gilmi.me/blog/post/2016/10/14/lisp-to-js
|
||||
|
||||
作者：[ Gil Mizrahi ][a]
|
||||
作者：[Gil Mizrahi][a]
|
||||
选题：[oska874][b]
|
||||
译者：[BriFuture](https://github.com/BriFuture)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -3,11 +3,11 @@
|
||||
|
||||
|
||||
|
||||
你可能已经知道，我们使用 mv 命令在类 Unix 操作系统中重命名或者移动文件和目录。 但是，mv 命令不支持一次重命名多个文件。 不用担心。 在本教程中，我们将学习使用 Linux 中的 “mmv” 命令一次重命名多个文件。 此命令用于在类 Unix 操作系统中使用标准通配符批量移动，复制，追加和重命名文件。
|
||||
你可能已经知道，我们使用 `mv` 命令在类 Unix 操作系统中重命名或者移动文件和目录。 但是，`mv` 命令不支持一次重命名多个文件。 不用担心。 在本教程中，我们将学习使用 Linux 中的 `mmv` 命令一次重命名多个文件。 此命令用于在类 Unix 操作系统中使用标准通配符批量移动、复制、追加和重命名文件。
|
||||
|
||||
### 在 Linux 中一次重命名多个文件
|
||||
|
||||
mmv 程序可在基于 Debian 的系统的默认仓库中使用。 要想在 Debian，Ubuntu，Linux Mint 上安装它，请运行以下命令：
|
||||
`mmv` 程序可在基于 Debian 的系统的默认仓库中使用。 要想在 Debian、Ubuntu、Linux Mint 上安装它，请运行以下命令：
|
||||
|
||||
```
|
||||
$ sudo apt-get install mmv
|
||||
@ -20,7 +20,7 @@ $ ls
|
||||
a1.txt a2.txt a3.txt
|
||||
```
|
||||
|
||||
现在，你想要将所有以字母 “a” 开头的文件重命名为以 “b” 开头的。 当然，你可以在几秒钟内手动执行此操作。 但是想想你是否有数百个文件想要重命名？ 这是一个非常耗时的过程。 这时候 **mmv** 命令就很有帮助了。
|
||||
现在，你想要将所有以字母 “a” 开头的文件重命名为以 “b” 开头的。 当然，你可以在几秒钟内手动执行此操作。 但是想想你是否有数百个文件想要重命名？ 这是一个非常耗时的过程。 这时候 `mmv` 命令就很有帮助了。
|
||||
|
||||
要将所有以字母 “a” 开头的文件重命名为以字母 “b” 开头的，只需要运行：
|
||||
|
||||
@ -33,22 +33,20 @@ $ mmv a\* b\#1
|
||||
```
|
||||
$ ls
|
||||
b1.txt b2.txt b3.txt
|
||||
|
||||
```
|
||||
|
||||
如你所见，所有以字母 “a” 开头的文件（即 a1.txt，a2.txt，a3.txt）都重命名为 b1.txt，b2.txt，b3.txt。
|
||||
如你所见，所有以字母 “a” 开头的文件（即 `a1.txt`、`a2.txt`、`a3.txt`）都重命名为 `b1.txt`、`b2.txt`、`b3.txt`。
|
||||
|
||||
**解释**
|
||||
|
||||
在上面的例子中，第一个参数（a\\*）是 'from' 模式，第二个参数是 'to' 模式（b\\#1）。根据上面的例子，mmv 将查找任何以字母 'a' 开头的文件名，并根据第二个参数重命名匹配的文件，即 'to' 模式。我们使用通配符，例如用 '*'，'?' 和 '[]' 来匹配一个或多个任意字符。请注意，你必须避免使用通配符，否则它们将被 shell 扩展，mmv 将无法理解。
|
||||
在上面的例子中，第一个参数（`a\*`）是 “from” 模式，第二个参数是 “to” 模式（`b\#1`）。根据上面的例子，`mmv` 将查找任何以字母 “a” 开头的文件名，并根据第二个参数重命名匹配的文件，即 “to” 模式。我们可以使用通配符，例如用 `*`、`?` 和 `[]` 来匹配一个或多个任意字符。请注意，你必须转义使用通配符，否则它们将被 shell 扩展，`mmv` 将无法理解。
|
||||
|
||||
'to' 模式中的 '#1' 是通配符索引。它匹配 'from' 模式中的第一个通配符。 'to' 模式中的 '#2' 将匹配第二个通配符，依此类推。在我们的例子中，我们只有一个通配符（星号），所以我们写了一个 #1。并且，哈希标志也应该被转义。此外，你也可以用引号括起模式。
|
||||
“to” 模式中的 `#1` 是通配符索引。它匹配 “from” 模式中的第一个通配符。 “to” 模式中的 `#2` 将匹配第二个通配符（如果有的话），依此类推。在我们的例子中，我们只有一个通配符（星号），所以我们写了一个 `#1`。并且，`#` 符号也应该被转义。此外，你也可以用引号括起模式。
|
||||
|
||||
你甚至可以将具有特定扩展名的所有文件重命名为其他扩展名。例如，要将当前目录中的所有 **.txt** 文件重命名为 **.doc** 文件格式，只需运行：
|
||||
你甚至可以将具有特定扩展名的所有文件重命名为其他扩展名。例如，要将当前目录中的所有 `.txt` 文件重命名为 `.doc` 文件格式，只需运行：
|
||||
|
||||
```
|
||||
$ mmv \*.txt \#1.doc
|
||||
|
||||
```
|
||||
|
||||
这是另一个例子。 我们假设你有以下文件。
|
||||
@ -56,16 +54,14 @@ $ mmv \*.txt \#1.doc
|
||||
```
|
||||
$ ls
|
||||
abcd1.txt abcd2.txt abcd3.txt
|
||||
|
||||
```
|
||||
|
||||
你希望在当前目录下的所有文件中将第一次出现的 **abc** 替换为 **xyz**。 你会怎么做呢？
|
||||
你希望在当前目录下的所有文件中将第一次出现的 “abc” 替换为 “xyz”。 你会怎么做呢？
|
||||
|
||||
很简单。
|
||||
|
||||
```
|
||||
$ mmv '*abc*' '#1xyz#2'
|
||||
|
||||
```
|
||||
|
||||
请注意，在上面的示例中，模式被单引号括起来了。
|
||||
@ -75,77 +71,74 @@ $ mmv '*abc*' '#1xyz#2'
|
||||
```
|
||||
$ ls
|
||||
xyzd1.txt xyzd2.txt xyzd3.txt
|
||||
|
||||
```
|
||||
|
||||
看到没？ 文件 **abcd1.txt**，**abcd2.txt** 和 **abcd3.txt** 已经重命名为 **xyzd1.txt**，**xyzd2.txt** 和 **xyzd3.txt**。
|
||||
看到没？ 文件 `abcd1.txt`、`abcd2.txt` 和 `abcd3.txt` 已经重命名为 `xyzd1.txt`、`xyzd2.txt` 和 `xyzd3.txt`。
|
||||
|
||||
mmv 命令的另一个值得注意的功能是你可以使用 **-n** 选项打印输出而不是重命名文件，如下所示。
|
||||
`mmv` 命令的另一个值得注意的功能是你可以使用 `-n` 选项打印输出而不是重命名文件，如下所示。
|
||||
|
||||
```
|
||||
$ mmv -n a\* b\#1
|
||||
a1.txt -> b1.txt
|
||||
a2.txt -> b2.txt
|
||||
a3.txt -> b3.txt
|
||||
|
||||
```
|
||||
|
||||
这样，你可以在重命名文件之前简单地验证 mmv 命令实际执行的操作。
|
||||
这样，你可以在重命名文件之前简单地验证 `mmv` 命令实际执行的操作。
|
||||
|
||||
有关更多详细信息，请参阅 man 页面。
|
||||
|
||||
```
|
||||
$ man mmv
|
||||
|
||||
```
|
||||
|
||||
**更新：**
|
||||
### 更新：Thunar 文件管理器
|
||||
|
||||
**Thunar 文件管理器**默认具有内置**批量重命名**选项。 如果你正在使用thunar，那么重命名文件要比使用mmv命令容易得多。
|
||||
**Thunar 文件管理器**默认具有内置**批量重命名**选项。 如果你正在使用 Thunar，那么重命名文件要比使用 `mmv` 命令容易得多。
|
||||
|
||||
Thunar在大多数Linux发行版的默认仓库库中都可用。
|
||||
Thunar 在大多数 Linux 发行版的默认仓库库中都可用。
|
||||
|
||||
要在基于Arch的系统上安装它，请运行：
|
||||
要在基于 Arch 的系统上安装它，请运行：
|
||||
|
||||
```
|
||||
$ sudo pacman -S thunar
|
||||
```
|
||||
|
||||
在 RHEL，CentOS 上:
|
||||
在 RHEL、CentOS 上:
|
||||
|
||||
```
|
||||
$ sudo yum install thunar
|
||||
```
|
||||
|
||||
在 Fedora 上:
|
||||
|
||||
```
|
||||
$ sudo dnf install thunar
|
||||
|
||||
```
|
||||
|
||||
在 openSUSE 上:
|
||||
|
||||
```
|
||||
$ sudo zypper install thunar
|
||||
|
||||
```
|
||||
|
||||
在 Debian，Ubuntu，Linux Mint 上:
|
||||
在 Debian、Ubuntu、Linux Mint 上:
|
||||
|
||||
```
|
||||
$ sudo apt-get install thunar
|
||||
|
||||
```
|
||||
|
||||
安装后，你可以从菜单或应用程序启动器中启动批量重命名程序。 要从终端启动它，请使用以下命令：
|
||||
|
||||
```
|
||||
$ thunar -B
|
||||
|
||||
```
|
||||
|
||||
批量重命名就是这么回事。
|
||||
批量重命名方式如下。
|
||||
|
||||
![][1]
|
||||
|
||||
单击加号，然后选择要重命名的文件列表。 批量重命名可以重命名文件的名称，文件的后缀或者同事重命名文件的名称和后缀。 Thunar 目前支持以下批量重命名：
|
||||
单击“+”，然后选择要重命名的文件列表。 批量重命名可以重命名文件的名称、文件的后缀或者同时重命名文件的名称和后缀。 Thunar 目前支持以下批量重命名：
|
||||
|
||||
- 插入日期或时间
|
||||
- 插入或覆盖
|
||||
@ -158,9 +151,9 @@ $ thunar -B
|
||||
|
||||
![][2]
|
||||
|
||||
选择条件后，单击**重命名文件**选项来重命名文件。
|
||||
选择条件后，单击“重命名文件”选项来重命名文件。
|
||||
|
||||
你还可以通过选择两个或更多文件从 Thunar 中打开批量重命名器。 选择文件后，按F2或右键单击并选择**重命名**。
|
||||
你还可以通过选择两个或更多文件从 Thunar 中打开批量重命名器。 选择文件后，按 F2 或右键单击并选择“重命名”。
|
||||
|
||||
嗯，这就是本次的所有内容了。希望有所帮助。更多干货即将到来。敬请关注！
|
||||
|
||||
@ -173,10 +166,10 @@ via: https://www.ostechnix.com/how-to-rename-multiple-files-at-once-in-linux/
|
||||
作者：[SK][a]
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
译者：[Flowsnow](https://github.com/Flowsnow)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://www.ostechnix.com/author/sk/
|
||||
[1]: http://www.ostechnix.com/wp-content/uploads/2018/06/bulk-rename.png
|
||||
[2]: http://www.ostechnix.com/wp-content/uploads/2018/06/bulk-rename-1.png
|
||||
[2]: http://www.ostechnix.com/wp-content/uploads/2018/06/bulk-rename-1.png
|
||||
@ -0,0 +1,277 @@
|
||||
重启和关闭 Linux 系统的 6 个终端命令
|
||||
======
|
||||
|
||||
在 Linux 管理员的日程当中，有很多需要执行的任务，其中就有系统的重启和关闭。
|
||||
|
||||
对于 Linux 管理员来说，重启和关闭系统是其诸多风险操作中的一例，有时候，由于某些原因，这些操作可能无法挽回，他们需要更多的时间来排查问题。
|
||||
|
||||
在 Linux 命令行模式下我们可以执行这些任务。很多时候，由于熟悉命令行，Linux 管理员更倾向于在命令行下完成这些任务。
|
||||
|
||||
重启和关闭系统的 Linux 命令并不多，用户需要根据需要，选择合适的命令来完成任务。
|
||||
|
||||
以下所有命令都有其自身特点，并允许被 Linux 管理员使用.
|
||||
|
||||
**建议阅读：**
|
||||
|
||||
- [查看系统/服务器正常运行时间的 11 个方法][1]
|
||||
- [Tuptime 一款为 Linux 系统保存历史记录、统计运行时间工具][2]
|
||||
|
||||
系统重启和关闭之始，会通知所有已登录的用户和进程。当然，如果使用了时间参数，系统将拒绝新的用户登入。
|
||||
|
||||
执行此类操作之前，我建议您坚持复查，因为您只能得到很少的提示来确保这一切顺利。
|
||||
|
||||
下面陈列了一些步骤：
|
||||
|
||||
* 确保您拥有一个可以处理故障的控制台，以防之后可能会发生的问题。 VMWare 可以访问虚拟机，而 IPMI、iLO 和 iDRAC 可以访问物理服务器。
|
||||
* 您需要通过公司的流程，申请修改或故障的执行权直到得到许可。
|
||||
* 为安全着想，备份重要的配置文件，并保存到其他服务器上.
|
||||
* 验证日志文件（提前检查）
|
||||
* 和相关团队交流，比如数据库管理团队，应用团队等。
|
||||
* 通知数据库和应用服务人员关闭服务，并得到确定答复。
|
||||
* 使用适当的命令复盘操作，验证工作。
|
||||
* 最后，重启系统。
|
||||
* 验证日志文件，如果一切顺利，执行下一步操作，如果发现任何问题，对症排查。
|
||||
* 无论是回退版本还是运行程序，通知相关团队提出申请。
|
||||
* 对操作做适当守候，并将预期的一切正常的反馈给团队
|
||||
|
||||
使用下列命令执行这项任务。
|
||||
|
||||
* `shutdown`、`halt`、`poweroff`、`reboot` 命令：用来停机、重启或切断电源
|
||||
* `init` 命令：是 “initialization” 的简称，是系统启动的第一个进程。
|
||||
* `systemctl` 命令：systemd 是 Linux 系统和服务器的管理程序。
|
||||
|
||||
### 方案 1：如何使用 shutdown 命令关闭和重启 Linux 系统
|
||||
|
||||
`shutdown` 命令用于断电或重启本地和远程的 Linux 机器。它为高效完成作业提供多个选项。如果使用了时间参数，系统关闭的 5 分钟之前，会创建 `/run/nologin` 文件，以确保后续的登录会被拒绝。
|
||||
|
||||
通用语法如下：
|
||||
|
||||
```
|
||||
# shutdown [OPTION] [TIME] [MESSAGE]
|
||||
```
|
||||
|
||||
运行下面的命令来立即关闭 Linux 机器。它会立刻杀死所有进程，并关闭系统。
|
||||
|
||||
```
|
||||
# shutdown -h now
|
||||
```
|
||||
|
||||
* `-h`：如果不特指 `-halt` 选项，这等价于 `-poweroff` 选项。
|
||||
|
||||
另外我们可以使用带有 `-halt` 选项的 `shutdown` 命令来立即关闭设备。
|
||||
|
||||
```
|
||||
# shutdown --halt now
|
||||
或者
|
||||
# shutdown -H now
|
||||
```
|
||||
|
||||
* `-H, --halt`：停止设备运行
|
||||
|
||||
另外我们可以使用带有 `poweroff` 选项的 `shutdown` 命令来立即关闭设备。
|
||||
|
||||
```
|
||||
# shutdown --poweroff now
|
||||
或者
|
||||
# shutdown -P now
|
||||
```
|
||||
|
||||
* `-P, --poweroff`：切断电源（默认）。
|
||||
|
||||
如果您没有使用时间选项运行下面的命令，它将会在一分钟后执行给出的命令。
|
||||
|
||||
```
|
||||
# shutdown -h
|
||||
Shutdown scheduled for Mon 2018-10-08 06:42:31 EDT, use 'shutdown -c' to cancel.
|
||||
|
||||
root@2daygeek.com#
|
||||
Broadcast message from root@vps.2daygeek.com (Mon 2018-10-08 06:41:31 EDT):
|
||||
|
||||
The system is going down for power-off at Mon 2018-10-08 06:42:31 EDT!
|
||||
```
|
||||
|
||||
其他的登录用户都能在中断中看到如下的广播消息：
|
||||
|
||||
```
|
||||
[daygeek@2daygeek.com ~]$
|
||||
Broadcast message from root@2daygeek.com (Mon 2018-10-08 06:41:31 EDT):
|
||||
|
||||
The system is going down for power-off at Mon 2018-10-08 06:42:31 EDT!
|
||||
```
|
||||
|
||||
对于使用了 `-halt` 选项：
|
||||
|
||||
```
|
||||
# shutdown -H
|
||||
Shutdown scheduled for Mon 2018-10-08 06:37:53 EDT, use 'shutdown -c' to cancel.
|
||||
|
||||
root@2daygeek.com#
|
||||
Broadcast message from root@vps.2daygeek.com (Mon 2018-10-08 06:36:53 EDT):
|
||||
|
||||
The system is going down for system halt at Mon 2018-10-08 06:37:53 EDT!
|
||||
```
|
||||
|
||||
对于使用了 `-poweroff` 选项：
|
||||
|
||||
```
|
||||
# shutdown -P
|
||||
Shutdown scheduled for Mon 2018-10-08 06:40:07 EDT, use 'shutdown -c' to cancel.
|
||||
|
||||
root@2daygeek.com#
|
||||
Broadcast message from root@vps.2daygeek.com (Mon 2018-10-08 06:39:07 EDT):
|
||||
|
||||
The system is going down for power-off at Mon 2018-10-08 06:40:07 EDT!
|
||||
```
|
||||
|
||||
可以在您的终端上敲击 `shutdown -c` 选项取消操作。
|
||||
|
||||
```
|
||||
# shutdown -c
|
||||
|
||||
Broadcast message from root@vps.2daygeek.com (Mon 2018-10-08 06:39:09 EDT):
|
||||
|
||||
The system shutdown has been cancelled at Mon 2018-10-08 06:40:09 EDT!
|
||||
```
|
||||
|
||||
其他的登录用户都能在中断中看到如下的广播消息：
|
||||
|
||||
```
|
||||
[daygeek@2daygeek.com ~]$
|
||||
Broadcast message from root@vps.2daygeek.com (Mon 2018-10-08 06:41:35 EDT):
|
||||
|
||||
The system shutdown has been cancelled at Mon 2018-10-08 06:42:35 EDT!
|
||||
```
|
||||
|
||||
添加时间参数，如果你想在 `N` 秒之后执行关闭或重启操作。这里，您可以为所有登录用户添加自定义广播消息。例如，我们将在五分钟后重启设备。
|
||||
|
||||
```
|
||||
# shutdown -r +5 "To activate the latest Kernel"
|
||||
Shutdown scheduled for Mon 2018-10-08 07:13:16 EDT, use 'shutdown -c' to cancel.
|
||||
|
||||
[root@vps138235 ~]#
|
||||
Broadcast message from root@vps.2daygeek.com (Mon 2018-10-08 07:08:16 EDT):
|
||||
|
||||
To activate the latest Kernel
|
||||
The system is going down for reboot at Mon 2018-10-08 07:13:16 EDT!
|
||||
```
|
||||
|
||||
运行下面的命令立即重启 Linux 机器。它会立即杀死所有进程并且重新启动系统。
|
||||
|
||||
```
|
||||
# shutdown -r now
|
||||
```
|
||||
|
||||
* `-r, --reboot`： 重启设备。
|
||||
|
||||
### 方案 2：如何通过 reboot 命令关闭和重启 Linux 系统
|
||||
|
||||
`reboot` 命令用于关闭和重启本地或远程设备。`reboot` 命令拥有两个实用的选项。
|
||||
|
||||
它能够优雅的关闭和重启设备（就好像在系统菜单中惦记重启选项一样简单）。
|
||||
|
||||
执行不带任何参数的 `reboot` 命令来重启 Linux 机器。
|
||||
|
||||
```
|
||||
# reboot
|
||||
```
|
||||
|
||||
执行带 `-p` 参数的 `reboot` 命令来关闭 Linux 机器电源。
|
||||
|
||||
```
|
||||
# reboot -p
|
||||
```
|
||||
|
||||
* `-p, --poweroff`：调用 `halt` 或 `poweroff` 命令，切断设备电源。
|
||||
|
||||
执行带 `-f` 参数的 `reboot` 命令来强制重启 Linux 设备（这类似按压机器上的电源键）。
|
||||
|
||||
```
|
||||
# reboot -f
|
||||
```
|
||||
|
||||
* `-f, --force`：立刻强制中断，切断电源或重启。
|
||||
|
||||
### 方案 3：如何通过 init 命令关闭和重启 Linux 系统
|
||||
|
||||
`init`（“initialization” 的简写）是系统启动的第一个进程。
|
||||
|
||||
它将会检查 `/etc/inittab` 文件并决定 linux 运行级别。同时，允许用户在 Linux 设备上执行关机或重启操作. 这里存在从 `0` 到 `6` 的七个运行等级。
|
||||
|
||||
**建议阅读：**
|
||||
|
||||
- [如何检查 Linux 上所有运行的服务][3]
|
||||
|
||||
执行以下 `init` 命令关闭系统。
|
||||
|
||||
```
|
||||
# init 0
|
||||
```
|
||||
|
||||
* `0`： 停机 – 关闭系统。
|
||||
|
||||
运行下面的 `init` 命令重启设备：
|
||||
|
||||
```
|
||||
# init 6
|
||||
```
|
||||
|
||||
* `6`：重启 – 重启设备。
|
||||
|
||||
### 方案 4：如何通过 halt 命令关闭和重启 Linux 系统
|
||||
|
||||
`halt` 命令用来切断电源或关闭远程 Linux 机器或本地主机。
|
||||
中断所有进程并关闭 cpu。
|
||||
|
||||
```
|
||||
# halt
|
||||
```
|
||||
|
||||
### 方案 5：如何通过 poweroff 命令关闭和重启 Linux 系统
|
||||
|
||||
`poweroff` 命令用来切断电源或关闭远程 Linux 机器或本地主机。 `poweroff` 很像 `halt`，但是它可以关闭设备硬件（灯和其他 PC 上的其它东西）。它会给主板发送 ACPI 指令，然后信号发送到电源，切断电源。
|
||||
|
||||
```
|
||||
# poweroff
|
||||
```
|
||||
|
||||
### 方案 6：如何通过 systemctl 命令关闭和重启 Linux 系统
|
||||
|
||||
systemd 是一款适用于所有主流 Linux 发型版的全新 init 系统和系统管理器，而不是传统的 SysV init 系统。
|
||||
|
||||
systemd 兼容与 SysV 和 LSB 初始化脚本。它能够替代 SysV init 系统。systemd 是内核启动的第一个进程，并持有序号为 1 的进程 PID。
|
||||
|
||||
**建议阅读：**
|
||||
|
||||
- [chkservice – 一款终端下系统单元管理工具][4]
|
||||
|
||||
它是一切进程的父进程，Fedora 15 是第一个适配安装 systemd （替代了 upstart）的发行版。
|
||||
|
||||
`systemctl` 是命令行下管理 systemd 守护进程和服务的主要工具（如 `start`、`restart`、`stop`、`enable`、`disable`、`reload` & `status`）。
|
||||
|
||||
systemd 使用 .service 文件而不是 SysV init 使用的 bash 脚本。 systemd 将所有守护进程归与自身的 Linux cgroups 用户组下，您可以浏览 `/cgroup/systemd` 文件查看该系统层次等级。
|
||||
|
||||
```
|
||||
# systemctl halt
|
||||
# systemctl poweroff
|
||||
# systemctl reboot
|
||||
# systemctl suspend
|
||||
# systemctl hibernate
|
||||
```
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.2daygeek.com/6-commands-to-shutdown-halt-poweroff-reboot-the-linux-system/
|
||||
|
||||
作者：[Prakash Subramanian][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[cyleft](https://github.com/cyleft)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://www.2daygeek.com/author/prakash/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://www.2daygeek.com/11-methods-to-find-check-system-server-uptime-in-linux/
|
||||
[2]: https://www.2daygeek.com/tuptime-a-tool-to-report-the-historical-and-statistical-running-time-of-linux-system/
|
||||
[3]: https://www.2daygeek.com/how-to-check-all-running-services-in-linux/
|
||||
[4]: https://www.2daygeek.com/chkservice-a-tool-for-managing-systemd-units-from-linux-terminal/
|
||||
@ -1,5 +1,6 @@
|
||||
MidnightBSD 发布 1.0！看看有哪些新的东西
|
||||
MidnightBSD 发布 1.0！
|
||||
======
|
||||
|
||||
几天前，Lucas Holt 宣布发布 MidnightBSD 1.0。让我们快速看一下这个新版本中包含的内容。
|
||||
|
||||
### 什么是 MidnightBSD？
|
||||
@ -10,15 +11,13 @@ MidnightBSD 发布 1.0！看看有哪些新的东西
|
||||
|
||||
### MidnightBSD 1.0 中有什么？
|
||||
|
||||
根据[发布说明][3]，1.0 中的大部分工作都是更新基础系统，改进包管理器和更新工具。新版本与 FreeBSD 10-Stable 兼容。
|
||||
根据[发布说明][3]（[视频](https://www.youtube.com/embed/-rlk2wFsjJ4)），1.0 中的大部分工作都是更新基础系统，改进包管理器和更新工具。新版本与 FreeBSD 10-Stable 兼容。
|
||||
|
||||
Mports（MidnightBSD 的包管理系统）已经升级支持使用一个命令安装多个包。`mport upgrade` 命令已经修复。Mports 现在会跟踪已弃用和过期的包。它还引入了新的包格式。
|
||||
|
||||
<https://www.youtube.com/embed/-rlk2wFsjJ4>
|
||||
|
||||
其他变化包括：
|
||||
|
||||
* 现在支持 [ZFS][4] 作为启动文件系统。以前，ZFS 只能用于额外存储。
|
||||
* 现在支持 [ZFS][4] 作为启动文件系统。以前，ZFS 只能用于附加存储。
|
||||
* 支持 NVME SSD。
|
||||
* AMD Ryzen 和 Radeon 的支持得到了改善。
|
||||
* Intel、Broadcom 和其他驱动程序已更新。
|
||||
@ -27,15 +26,13 @@ Mports（MidnightBSD 的包管理系统）已经升级支持使用一个命令
|
||||
* 删除了 Sudo 并用 OpenBSD 中的 [doas][5] 替换。
|
||||
* 增加了对 Microsoft hyper-v 的支持。
|
||||
|
||||
|
||||
|
||||
### 升级之前
|
||||
|
||||
如果你当前是 MidnightBSD 的用户或正在考虑尝试新版本，那么还是再等一会。Lucas 目前正在重建软件包以支持新的软件包格式和工具。他还计划在未来几个月内升级软件包和移植桌面环境。他目前正致力于移植 Firefox 52 ESR，因为它是最后一个不需要 Rust 的版本。他还希望将更新版本的 Chromium 移植到 MidnightBSD。我建议关注 MidnightBSD 的 [Twitter][6]。
|
||||
|
||||
### 0.9怎么回事？
|
||||
### 0.9 怎么回事？
|
||||
|
||||
你可能注意到 MidnightBSD 的先前版本是 0.8.6。你现在可能想知道“为什么跳到 1.0”？根据 Lucas 的说法，他在开发 0.9 时遇到了几个问题。事实上，他重试好几次。他最终采用与 0.9 分支不同的方式，并变成了 1.0。有些软件包也存在 0.* 编号系统的问题。
|
||||
你可能注意到 MidnightBSD 的先前版本是 0.8.6。你现在可能想知道“为什么跳到 1.0”？根据 Lucas 的说法，他在开发 0.9 时遇到了几个问题。事实上，他重试好几次。他最终采用与 0.9 分支不同的方式，并变成了 1.0。有些软件包在 0.* 系列也有问题。
|
||||
|
||||
### 需要帮助
|
||||
|
||||
@ -58,7 +55,7 @@ via: https://itsfoss.com/midnightbsd-1-0-release/
|
||||
作者：[John Paul][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -1,135 +0,0 @@
|
||||
Translating by Felix
|
||||
20 questions DevOps job candidates should be prepared to answer
|
||||
======
|
||||
|
||||
|
||||
Hiring the wrong person is [expensive][1]. Recruiting, hiring, and onboarding a new employee can cost a company as much as $240,000, according to Jörgen Sundberg, CEO of Link Humans. When you make the wrong hire:
|
||||
|
||||
* You lose what they know.
|
||||
* You lose who they know.
|
||||
* Your team could go into the [storming][2] phase of group development.
|
||||
* Your company risks disorganization.
|
||||
|
||||
|
||||
|
||||
When you lose an employee, you lose a piece of the fabric of the company. It's also worth mentioning the pain on the other end. The person hired into the wrong job may experience stress, feelings of overall dissatisfaction, and even health issues.
|
||||
|
||||
On the other hand, when you get it right, your new hire will:
|
||||
|
||||
* Enhance the existing culture, making your organization an even a better place to work. Studies show that a positive work culture helps [drive long-term financial performance][3] and that if you work in a happy environment, you’re more likely to do better in life.
|
||||
* Love working with your organization. When people love what they do, they tend to do it well.
|
||||
|
||||
|
||||
|
||||
Hiring to fit or enhance your existing culture is essential in DevOps and agile teams. That means hiring someone who can encourage effective collaboration so that individual contributors from varying backgrounds, and teams with different goals and working styles, can work together productively. Your new hire should help teams collaborate to maximize their value while also increasing employee satisfaction and balancing conflicting organizational goals. He or she should be able to choose tools and workflows wisely to complement your organization. Culture is everything.
|
||||
|
||||
As a follow-up to our November 2017 post, [20 questions DevOps hiring managers should be prepared to answer][4], this article will focus on how to hire for the best mutual fit.
|
||||
|
||||
### Why hiring goes wrong
|
||||
|
||||
The typical hiring strategy many companies use today is based on a talent surplus:
|
||||
|
||||
* Post on job boards.
|
||||
* Focus on candidates with the skills they need.
|
||||
* Find as many candidates as possible.
|
||||
* Interview to weed out the weak.
|
||||
* Conduct formal interviews to do more weeding.
|
||||
* Assess, vote, and select.
|
||||
* Close on compensation.
|
||||
|
||||
|
||||
|
||||
Job boards were invented during the Great Depression when millions of people were out of work and there was a talent surplus. There is no talent surplus in today's job market, yet we’re still using a hiring strategy that's based on one.
|
||||
|
||||
|
||||
|
||||
### Hire for mutual fit: Use culture and emotions
|
||||
|
||||
The idea behind the talent surplus hiring strategy is to design jobs and then slot people into them.
|
||||
|
||||
Instead, do the opposite: Find talented people who will positively add to your business culture, then find the best fit for them in a job they’ll love. To do this, you must be open to creating jobs around their passions.
|
||||
|
||||
**Who is looking for a job?** According to a 2016 survey of more than 50,000 U.S. developers, [85.7% of respondents][5] were either not interested in new opportunities or were not actively looking for them. And of those who were looking, a whopping [28.3% of job discoveries][5] came from referrals by friends. If you’re searching only for people who are looking for jobs, you’re missing out on top talent.
|
||||
|
||||
**Use your team to find and vet potential recruits**. For example, if Diane is a developer on your team, chances are she has [been coding for years][6] and has met fellow developers along the way who also love what they do. Wouldn’t you think her chances of vetting potential recruits for skills, knowledge, and intelligence would be higher than having someone from HR find and vet potential recruits? And before asking Diane to share her knowledge of fellow recruits, inform her of the upcoming mission, explain your desire to hire a diverse team of passionate explorers, and describe some of the areas where help will be needed in the future.
|
||||
|
||||
**What do employees want?** A comprehensive study comparing the wants and needs of Millennials, GenX’ers, and Baby Boomers shows that within two percentage points, we all [want the same things][7]:
|
||||
|
||||
1. To make a positive impact on the organization
|
||||
2. To help solve social and/or environmental challenges
|
||||
3. To work with a diverse group of people
|
||||
|
||||
|
||||
|
||||
### The interview challenge
|
||||
|
||||
The interview should be a two-way conversation for finding a mutual fit between the person hiring and the person interviewing. Focus your interview on CQ ([Cultural Quotient][7]) and EQ ([Emotional Quotient][8]): Will this person reinforce and add to your culture and love working with you? Can you help make them successful at their job?
|
||||
|
||||
**For the hiring manager:** Every interview is an opportunity to learn how your organization could become more irresistible to prospective team members, and every positive interview can be your best opportunity to finding talent, even if you don’t hire that person. Everyone remembers being interviewed if it is a positive experience. Even if they don’t get hired, they will talk about the experience with their friends, and you may get a referral as a result. There is a big upside to this: If you’re not attracting this talent, you have the opportunity to learn the reason and fix it.
|
||||
|
||||
**For the interviewee** : Each interview experience is an opportunity to unlock your passions.
|
||||
|
||||
### 20 questions to help you unlock the passions of potential hires
|
||||
|
||||
1. What are you passionate about?
|
||||
|
||||
2. What makes you think, "I can't wait to get to work this morning!”
|
||||
|
||||
3. What is the most fun you’ve ever had?
|
||||
|
||||
4. What is your favorite example of a problem you’ve solved, and how did you solve it?
|
||||
|
||||
5. How do you feel about paired learning?
|
||||
|
||||
6. What’s at the top of your mind when you arrive at, and leave, the office?
|
||||
|
||||
7. If you could have changed one thing in your previous/current job, what would it be?
|
||||
|
||||
8. What are you excited to learn while working here?
|
||||
|
||||
9. What do you aspire to in life, and how are you pursuing it?
|
||||
|
||||
10. What do you want, or feel you need, to learn to achieve these aspirations?
|
||||
|
||||
11. What values do you hold?
|
||||
|
||||
12. How do you live those values?
|
||||
|
||||
13. What does balance mean in your life?
|
||||
|
||||
14. What work interactions are you are most proud of? Why?
|
||||
|
||||
15. What type of environment do you like to create?
|
||||
|
||||
16. How do you like to be treated?
|
||||
|
||||
17. What do you trust vs. verify?
|
||||
|
||||
18. Tell me about a recent learning you had when working on a project.
|
||||
|
||||
19. What else should we know about you?
|
||||
|
||||
20. If you were hiring me, what questions would you ask me?
|
||||
|
||||
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/3/questions-devops-employees-should-answer
|
||||
|
||||
作者：[Catherine Louis][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://opensource.com/users/catherinelouis
|
||||
[1]:https://www.shrm.org/resourcesandtools/hr-topics/employee-relations/pages/cost-of-bad-hires.aspx
|
||||
[2]:https://en.wikipedia.org/wiki/Tuckman%27s_stages_of_group_development
|
||||
[3]:http://www.forbes.com/sites/johnkotter/2011/02/10/does-corporate-culture-drive-financial-performance/
|
||||
[4]:https://opensource.com/article/17/11/inclusive-workforce-takes-work
|
||||
[5]:https://insights.stackoverflow.com/survey/2016#work-job-discovery
|
||||
[6]:https://research.hackerrank.com/developer-skills/2018/
|
||||
[7]:http://www-935.ibm.com/services/us/gbs/thoughtleadership/millennialworkplace/
|
||||
[8]:https://en.wikipedia.org/wiki/Emotional_intelligence
|
||||
@ -1,3 +1,5 @@
|
||||
translating by belitex
|
||||
|
||||
What breaks our systems: A taxonomy of black swans
|
||||
======
|
||||
|
||||
|
||||
@ -1,4 +1,3 @@
|
||||
Translating by z52527
|
||||
Publishing Markdown to HTML with MDwiki
|
||||
======
|
||||
|
||||
|
||||
@ -1,596 +0,0 @@
|
||||
Translating by qhwdw
|
||||
Lab 4: Preemptive Multitasking
|
||||
======
|
||||
### Lab 4: Preemptive Multitasking
|
||||
|
||||
**Part A due Thursday, October 18, 2018
|
||||
Part B due Thursday, October 25, 2018
|
||||
Part C due Thursday, November 1, 2018**
|
||||
|
||||
#### Introduction
|
||||
|
||||
In this lab you will implement preemptive multitasking among multiple simultaneously active user-mode environments.
|
||||
|
||||
In part A you will add multiprocessor support to JOS, implement round-robin scheduling, and add basic environment management system calls (calls that create and destroy environments, and allocate/map memory).
|
||||
|
||||
In part B, you will implement a Unix-like `fork()`, which allows a user-mode environment to create copies of itself.
|
||||
|
||||
Finally, in part C you will add support for inter-process communication (IPC), allowing different user-mode environments to communicate and synchronize with each other explicitly. You will also add support for hardware clock interrupts and preemption.
|
||||
|
||||
##### Getting Started
|
||||
|
||||
Use Git to commit your Lab 3 source, fetch the latest version of the course repository, and then create a local branch called `lab4` based on our lab4 branch, `origin/lab4`:
|
||||
|
||||
```
|
||||
athena% cd ~/6.828/lab
|
||||
athena% add git
|
||||
athena% git pull
|
||||
Already up-to-date.
|
||||
athena% git checkout -b lab4 origin/lab4
|
||||
Branch lab4 set up to track remote branch refs/remotes/origin/lab4.
|
||||
Switched to a new branch "lab4"
|
||||
athena% git merge lab3
|
||||
Merge made by recursive.
|
||||
...
|
||||
athena%
|
||||
```
|
||||
|
||||
Lab 4 contains a number of new source files, some of which you should browse before you start:
|
||||
| kern/cpu.h | Kernel-private definitions for multiprocessor support |
|
||||
| kern/mpconfig.c | Code to read the multiprocessor configuration |
|
||||
| kern/lapic.c | Kernel code driving the local APIC unit in each processor |
|
||||
| kern/mpentry.S | Assembly-language entry code for non-boot CPUs |
|
||||
| kern/spinlock.h | Kernel-private definitions for spin locks, including the big kernel lock |
|
||||
| kern/spinlock.c | Kernel code implementing spin locks |
|
||||
| kern/sched.c | Code skeleton of the scheduler that you are about to implement |
|
||||
|
||||
##### Lab Requirements
|
||||
|
||||
This lab is divided into three parts, A, B, and C. We have allocated one week in the schedule for each part.
|
||||
|
||||
As before, you will need to do all of the regular exercises described in the lab and _at least one_ challenge problem. (You do not need to do one challenge problem per part, just one for the whole lab.) Additionally, you will need to write up a brief description of the challenge problem that you implemented. If you implement more than one challenge problem, you only need to describe one of them in the write-up, though of course you are welcome to do more. Place the write-up in a file called `answers-lab4.txt` in the top level of your `lab` directory before handing in your work.
|
||||
|
||||
#### Part A: Multiprocessor Support and Cooperative Multitasking
|
||||
|
||||
In the first part of this lab, you will first extend JOS to run on a multiprocessor system, and then implement some new JOS kernel system calls to allow user-level environments to create additional new environments. You will also implement _cooperative_ round-robin scheduling, allowing the kernel to switch from one environment to another when the current environment voluntarily relinquishes the CPU (or exits). Later in part C you will implement _preemptive_ scheduling, which allows the kernel to re-take control of the CPU from an environment after a certain time has passed even if the environment does not cooperate.
|
||||
|
||||
##### Multiprocessor Support
|
||||
|
||||
We are going to make JOS support "symmetric multiprocessing" (SMP), a multiprocessor model in which all CPUs have equivalent access to system resources such as memory and I/O buses. While all CPUs are functionally identical in SMP, during the boot process they can be classified into two types: the bootstrap processor (BSP) is responsible for initializing the system and for booting the operating system; and the application processors (APs) are activated by the BSP only after the operating system is up and running. Which processor is the BSP is determined by the hardware and the BIOS. Up to this point, all your existing JOS code has been running on the BSP.
|
||||
|
||||
In an SMP system, each CPU has an accompanying local APIC (LAPIC) unit. The LAPIC units are responsible for delivering interrupts throughout the system. The LAPIC also provides its connected CPU with a unique identifier. In this lab, we make use of the following basic functionality of the LAPIC unit (in `kern/lapic.c`):
|
||||
|
||||
* Reading the LAPIC identifier (APIC ID) to tell which CPU our code is currently running on (see `cpunum()`).
|
||||
* Sending the `STARTUP` interprocessor interrupt (IPI) from the BSP to the APs to bring up other CPUs (see `lapic_startap()`).
|
||||
* In part C, we program LAPIC's built-in timer to trigger clock interrupts to support preemptive multitasking (see `apic_init()`).
|
||||
|
||||
|
||||
|
||||
A processor accesses its LAPIC using memory-mapped I/O (MMIO). In MMIO, a portion of _physical_ memory is hardwired to the registers of some I/O devices, so the same load/store instructions typically used to access memory can be used to access device registers. You've already seen one IO hole at physical address `0xA0000` (we use this to write to the VGA display buffer). The LAPIC lives in a hole starting at physical address `0xFE000000` (32MB short of 4GB), so it's too high for us to access using our usual direct map at KERNBASE. The JOS virtual memory map leaves a 4MB gap at `MMIOBASE` so we have a place to map devices like this. Since later labs introduce more MMIO regions, you'll write a simple function to allocate space from this region and map device memory to it.
|
||||
|
||||
```
|
||||
Exercise 1. Implement `mmio_map_region` in `kern/pmap.c`. To see how this is used, look at the beginning of `lapic_init` in `kern/lapic.c`. You'll have to do the next exercise, too, before the tests for `mmio_map_region` will run.
|
||||
```
|
||||
|
||||
###### Application Processor Bootstrap
|
||||
|
||||
Before booting up APs, the BSP should first collect information about the multiprocessor system, such as the total number of CPUs, their APIC IDs and the MMIO address of the LAPIC unit. The `mp_init()` function in `kern/mpconfig.c` retrieves this information by reading the MP configuration table that resides in the BIOS's region of memory.
|
||||
|
||||
The `boot_aps()` function (in `kern/init.c`) drives the AP bootstrap process. APs start in real mode, much like how the bootloader started in `boot/boot.S`, so `boot_aps()` copies the AP entry code (`kern/mpentry.S`) to a memory location that is addressable in the real mode. Unlike with the bootloader, we have some control over where the AP will start executing code; we copy the entry code to `0x7000` (`MPENTRY_PADDR`), but any unused, page-aligned physical address below 640KB would work.
|
||||
|
||||
After that, `boot_aps()` activates APs one after another, by sending `STARTUP` IPIs to the LAPIC unit of the corresponding AP, along with an initial `CS:IP` address at which the AP should start running its entry code (`MPENTRY_PADDR` in our case). The entry code in `kern/mpentry.S` is quite similar to that of `boot/boot.S`. After some brief setup, it puts the AP into protected mode with paging enabled, and then calls the C setup routine `mp_main()` (also in `kern/init.c`). `boot_aps()` waits for the AP to signal a `CPU_STARTED` flag in `cpu_status` field of its `struct CpuInfo` before going on to wake up the next one.
|
||||
|
||||
```
|
||||
Exercise 2. Read `boot_aps()` and `mp_main()` in `kern/init.c`, and the assembly code in `kern/mpentry.S`. Make sure you understand the control flow transfer during the bootstrap of APs. Then modify your implementation of `page_init()` in `kern/pmap.c` to avoid adding the page at `MPENTRY_PADDR` to the free list, so that we can safely copy and run AP bootstrap code at that physical address. Your code should pass the updated `check_page_free_list()` test (but might fail the updated `check_kern_pgdir()` test, which we will fix soon).
|
||||
```
|
||||
|
||||
```
|
||||
Question
|
||||
|
||||
1. Compare `kern/mpentry.S` side by side with `boot/boot.S`. Bearing in mind that `kern/mpentry.S` is compiled and linked to run above `KERNBASE` just like everything else in the kernel, what is the purpose of macro `MPBOOTPHYS`? Why is it necessary in `kern/mpentry.S` but not in `boot/boot.S`? In other words, what could go wrong if it were omitted in `kern/mpentry.S`?
|
||||
Hint: recall the differences between the link address and the load address that we have discussed in Lab 1.
|
||||
```
|
||||
|
||||
|
||||
###### Per-CPU State and Initialization
|
||||
|
||||
When writing a multiprocessor OS, it is important to distinguish between per-CPU state that is private to each processor, and global state that the whole system shares. `kern/cpu.h` defines most of the per-CPU state, including `struct CpuInfo`, which stores per-CPU variables. `cpunum()` always returns the ID of the CPU that calls it, which can be used as an index into arrays like `cpus`. Alternatively, the macro `thiscpu` is shorthand for the current CPU's `struct CpuInfo`.
|
||||
|
||||
Here is the per-CPU state you should be aware of:
|
||||
|
||||
* **Per-CPU kernel stack**.
|
||||
Because multiple CPUs can trap into the kernel simultaneously, we need a separate kernel stack for each processor to prevent them from interfering with each other's execution. The array `percpu_kstacks[NCPU][KSTKSIZE]` reserves space for NCPU's worth of kernel stacks.
|
||||
|
||||
In Lab 2, you mapped the physical memory that `bootstack` refers to as the BSP's kernel stack just below `KSTACKTOP`. Similarly, in this lab, you will map each CPU's kernel stack into this region with guard pages acting as a buffer between them. CPU 0's stack will still grow down from `KSTACKTOP`; CPU 1's stack will start `KSTKGAP` bytes below the bottom of CPU 0's stack, and so on. `inc/memlayout.h` shows the mapping layout.
|
||||
|
||||
* **Per-CPU TSS and TSS descriptor**.
|
||||
A per-CPU task state segment (TSS) is also needed in order to specify where each CPU's kernel stack lives. The TSS for CPU _i_ is stored in `cpus[i].cpu_ts`, and the corresponding TSS descriptor is defined in the GDT entry `gdt[(GD_TSS0 >> 3) + i]`. The global `ts` variable defined in `kern/trap.c` will no longer be useful.
|
||||
|
||||
* **Per-CPU current environment pointer**.
|
||||
Since each CPU can run different user process simultaneously, we redefined the symbol `curenv` to refer to `cpus[cpunum()].cpu_env` (or `thiscpu->cpu_env`), which points to the environment _currently_ executing on the _current_ CPU (the CPU on which the code is running).
|
||||
|
||||
* **Per-CPU system registers**.
|
||||
All registers, including system registers, are private to a CPU. Therefore, instructions that initialize these registers, such as `lcr3()`, `ltr()`, `lgdt()`, `lidt()`, etc., must be executed once on each CPU. Functions `env_init_percpu()` and `trap_init_percpu()` are defined for this purpose.
|
||||
|
||||
|
||||
|
||||
```
|
||||
Exercise 3. Modify `mem_init_mp()` (in `kern/pmap.c`) to map per-CPU stacks starting at `KSTACKTOP`, as shown in `inc/memlayout.h`. The size of each stack is `KSTKSIZE` bytes plus `KSTKGAP` bytes of unmapped guard pages. Your code should pass the new check in `check_kern_pgdir()`.
|
||||
```
|
||||
|
||||
```
|
||||
Exercise 4. The code in `trap_init_percpu()` (`kern/trap.c`) initializes the TSS and TSS descriptor for the BSP. It worked in Lab 3, but is incorrect when running on other CPUs. Change the code so that it can work on all CPUs. (Note: your new code should not use the global `ts` variable any more.)
|
||||
```
|
||||
|
||||
When you finish the above exercises, run JOS in QEMU with 4 CPUs using make qemu CPUS=4 (or make qemu-nox CPUS=4), you should see output like this:
|
||||
|
||||
```
|
||||
...
|
||||
Physical memory: 66556K available, base = 640K, extended = 65532K
|
||||
check_page_alloc() succeeded!
|
||||
check_page() succeeded!
|
||||
check_kern_pgdir() succeeded!
|
||||
check_page_installed_pgdir() succeeded!
|
||||
SMP: CPU 0 found 4 CPU(s)
|
||||
enabled interrupts: 1 2
|
||||
SMP: CPU 1 starting
|
||||
SMP: CPU 2 starting
|
||||
SMP: CPU 3 starting
|
||||
```
|
||||
|
||||
###### Locking
|
||||
|
||||
Our current code spins after initializing the AP in `mp_main()`. Before letting the AP get any further, we need to first address race conditions when multiple CPUs run kernel code simultaneously. The simplest way to achieve this is to use a _big kernel lock_. The big kernel lock is a single global lock that is held whenever an environment enters kernel mode, and is released when the environment returns to user mode. In this model, environments in user mode can run concurrently on any available CPUs, but no more than one environment can run in kernel mode; any other environments that try to enter kernel mode are forced to wait.
|
||||
|
||||
`kern/spinlock.h` declares the big kernel lock, namely `kernel_lock`. It also provides `lock_kernel()` and `unlock_kernel()`, shortcuts to acquire and release the lock. You should apply the big kernel lock at four locations:
|
||||
|
||||
* In `i386_init()`, acquire the lock before the BSP wakes up the other CPUs.
|
||||
* In `mp_main()`, acquire the lock after initializing the AP, and then call `sched_yield()` to start running environments on this AP.
|
||||
* In `trap()`, acquire the lock when trapped from user mode. To determine whether a trap happened in user mode or in kernel mode, check the low bits of the `tf_cs`.
|
||||
* In `env_run()`, release the lock _right before_ switching to user mode. Do not do that too early or too late, otherwise you will experience races or deadlocks.
|
||||
|
||||
|
||||
```
|
||||
Exercise 5. Apply the big kernel lock as described above, by calling `lock_kernel()` and `unlock_kernel()` at the proper locations.
|
||||
```
|
||||
|
||||
How to test if your locking is correct? You can't at this moment! But you will be able to after you implement the scheduler in the next exercise.
|
||||
|
||||
```
|
||||
Question
|
||||
|
||||
2. It seems that using the big kernel lock guarantees that only one CPU can run the kernel code at a time. Why do we still need separate kernel stacks for each CPU? Describe a scenario in which using a shared kernel stack will go wrong, even with the protection of the big kernel lock.
|
||||
```
|
||||
|
||||
```
|
||||
Challenge! The big kernel lock is simple and easy to use. Nevertheless, it eliminates all concurrency in kernel mode. Most modern operating systems use different locks to protect different parts of their shared state, an approach called _fine-grained locking_. Fine-grained locking can increase performance significantly, but is more difficult to implement and error-prone. If you are brave enough, drop the big kernel lock and embrace concurrency in JOS!
|
||||
|
||||
It is up to you to decide the locking granularity (the amount of data that a lock protects). As a hint, you may consider using spin locks to ensure exclusive access to these shared components in the JOS kernel:
|
||||
|
||||
* The page allocator.
|
||||
* The console driver.
|
||||
* The scheduler.
|
||||
* The inter-process communication (IPC) state that you will implement in the part C.
|
||||
```
|
||||
|
||||
|
||||
##### Round-Robin Scheduling
|
||||
|
||||
Your next task in this lab is to change the JOS kernel so that it can alternate between multiple environments in "round-robin" fashion. Round-robin scheduling in JOS works as follows:
|
||||
|
||||
* The function `sched_yield()` in the new `kern/sched.c` is responsible for selecting a new environment to run. It searches sequentially through the `envs[]` array in circular fashion, starting just after the previously running environment (or at the beginning of the array if there was no previously running environment), picks the first environment it finds with a status of `ENV_RUNNABLE` (see `inc/env.h`), and calls `env_run()` to jump into that environment.
|
||||
* `sched_yield()` must never run the same environment on two CPUs at the same time. It can tell that an environment is currently running on some CPU (possibly the current CPU) because that environment's status will be `ENV_RUNNING`.
|
||||
* We have implemented a new system call for you, `sys_yield()`, which user environments can call to invoke the kernel's `sched_yield()` function and thereby voluntarily give up the CPU to a different environment.
|
||||
|
||||
|
||||
|
||||
```
|
||||
Exercise 6. Implement round-robin scheduling in `sched_yield()` as described above. Don't forget to modify `syscall()` to dispatch `sys_yield()`.
|
||||
|
||||
Make sure to invoke `sched_yield()` in `mp_main`.
|
||||
|
||||
Modify `kern/init.c` to create three (or more!) environments that all run the program `user/yield.c`.
|
||||
|
||||
Run make qemu. You should see the environments switch back and forth between each other five times before terminating, like below.
|
||||
|
||||
Test also with several CPUS: make qemu CPUS=2.
|
||||
|
||||
...
|
||||
Hello, I am environment 00001000.
|
||||
Hello, I am environment 00001001.
|
||||
Hello, I am environment 00001002.
|
||||
Back in environment 00001000, iteration 0.
|
||||
Back in environment 00001001, iteration 0.
|
||||
Back in environment 00001002, iteration 0.
|
||||
Back in environment 00001000, iteration 1.
|
||||
Back in environment 00001001, iteration 1.
|
||||
Back in environment 00001002, iteration 1.
|
||||
...
|
||||
|
||||
After the `yield` programs exit, there will be no runnable environment in the system, the scheduler should invoke the JOS kernel monitor. If any of this does not happen, then fix your code before proceeding.
|
||||
```
|
||||
|
||||
```
|
||||
Question
|
||||
|
||||
3. In your implementation of `env_run()` you should have called `lcr3()`. Before and after the call to `lcr3()`, your code makes references (at least it should) to the variable `e`, the argument to `env_run`. Upon loading the `%cr3` register, the addressing context used by the MMU is instantly changed. But a virtual address (namely `e`) has meaning relative to a given address context--the address context specifies the physical address to which the virtual address maps. Why can the pointer `e` be dereferenced both before and after the addressing switch?
|
||||
4. Whenever the kernel switches from one environment to another, it must ensure the old environment's registers are saved so they can be restored properly later. Why? Where does this happen?
|
||||
```
|
||||
|
||||
```
|
||||
Challenge! Add a less trivial scheduling policy to the kernel, such as a fixed-priority scheduler that allows each environment to be assigned a priority and ensures that higher-priority environments are always chosen in preference to lower-priority environments. If you're feeling really adventurous, try implementing a Unix-style adjustable-priority scheduler or even a lottery or stride scheduler. (Look up "lottery scheduling" and "stride scheduling" in Google.)
|
||||
|
||||
Write a test program or two that verifies that your scheduling algorithm is working correctly (i.e., the right environments get run in the right order). It may be easier to write these test programs once you have implemented `fork()` and IPC in parts B and C of this lab.
|
||||
```
|
||||
|
||||
```
|
||||
Challenge! The JOS kernel currently does not allow applications to use the x86 processor's x87 floating-point unit (FPU), MMX instructions, or Streaming SIMD Extensions (SSE). Extend the `Env` structure to provide a save area for the processor's floating point state, and extend the context switching code to save and restore this state properly when switching from one environment to another. The `FXSAVE` and `FXRSTOR` instructions may be useful, but note that these are not in the old i386 user's manual because they were introduced in more recent processors. Write a user-level test program that does something cool with floating-point.
|
||||
```
|
||||
|
||||
##### System Calls for Environment Creation
|
||||
|
||||
Although your kernel is now capable of running and switching between multiple user-level environments, it is still limited to running environments that the _kernel_ initially set up. You will now implement the necessary JOS system calls to allow _user_ environments to create and start other new user environments.
|
||||
|
||||
Unix provides the `fork()` system call as its process creation primitive. Unix `fork()` copies the entire address space of calling process (the parent) to create a new process (the child). The only differences between the two observable from user space are their process IDs and parent process IDs (as returned by `getpid` and `getppid`). In the parent, `fork()` returns the child's process ID, while in the child, `fork()` returns 0. By default, each process gets its own private address space, and neither process's modifications to memory are visible to the other.
|
||||
|
||||
You will provide a different, more primitive set of JOS system calls for creating new user-mode environments. With these system calls you will be able to implement a Unix-like `fork()` entirely in user space, in addition to other styles of environment creation. The new system calls you will write for JOS are as follows:
|
||||
|
||||
* `sys_exofork`:
|
||||
This system call creates a new environment with an almost blank slate: nothing is mapped in the user portion of its address space, and it is not runnable. The new environment will have the same register state as the parent environment at the time of the `sys_exofork` call. In the parent, `sys_exofork` will return the `envid_t` of the newly created environment (or a negative error code if the environment allocation failed). In the child, however, it will return 0. (Since the child starts out marked as not runnable, `sys_exofork` will not actually return in the child until the parent has explicitly allowed this by marking the child runnable using....)
|
||||
* `sys_env_set_status`:
|
||||
Sets the status of a specified environment to `ENV_RUNNABLE` or `ENV_NOT_RUNNABLE`. This system call is typically used to mark a new environment ready to run, once its address space and register state has been fully initialized.
|
||||
* `sys_page_alloc`:
|
||||
Allocates a page of physical memory and maps it at a given virtual address in a given environment's address space.
|
||||
* `sys_page_map`:
|
||||
Copy a page mapping ( _not_ the contents of a page!) from one environment's address space to another, leaving a memory sharing arrangement in place so that the new and the old mappings both refer to the same page of physical memory.
|
||||
* `sys_page_unmap`:
|
||||
Unmap a page mapped at a given virtual address in a given environment.
|
||||
|
||||
|
||||
|
||||
For all of the system calls above that accept environment IDs, the JOS kernel supports the convention that a value of 0 means "the current environment." This convention is implemented by `envid2env()` in `kern/env.c`.
|
||||
|
||||
We have provided a very primitive implementation of a Unix-like `fork()` in the test program `user/dumbfork.c`. This test program uses the above system calls to create and run a child environment with a copy of its own address space. The two environments then switch back and forth using `sys_yield` as in the previous exercise. The parent exits after 10 iterations, whereas the child exits after 20.
|
||||
|
||||
```
|
||||
Exercise 7. Implement the system calls described above in `kern/syscall.c` and make sure `syscall()` calls them. You will need to use various functions in `kern/pmap.c` and `kern/env.c`, particularly `envid2env()`. For now, whenever you call `envid2env()`, pass 1 in the `checkperm` parameter. Be sure you check for any invalid system call arguments, returning `-E_INVAL` in that case. Test your JOS kernel with `user/dumbfork` and make sure it works before proceeding.
|
||||
```
|
||||
|
||||
```
|
||||
Challenge! Add the additional system calls necessary to _read_ all of the vital state of an existing environment as well as set it up. Then implement a user mode program that forks off a child environment, runs it for a while (e.g., a few iterations of `sys_yield()`), then takes a complete snapshot or _checkpoint_ of the child environment, runs the child for a while longer, and finally restores the child environment to the state it was in at the checkpoint and continues it from there. Thus, you are effectively "replaying" the execution of the child environment from an intermediate state. Make the child environment perform some interaction with the user using `sys_cgetc()` or `readline()` so that the user can view and mutate its internal state, and verify that with your checkpoint/restart you can give the child environment a case of selective amnesia, making it "forget" everything that happened beyond a certain point.
|
||||
```
|
||||
|
||||
This completes Part A of the lab; make sure it passes all of the Part A tests when you run make grade, and hand it in using make handin as usual. If you are trying to figure out why a particular test case is failing, run ./grade-lab4 -v, which will show you the output of the kernel builds and QEMU runs for each test, until a test fails. When a test fails, the script will stop, and then you can inspect `jos.out` to see what the kernel actually printed.
|
||||
|
||||
#### Part B: Copy-on-Write Fork
|
||||
|
||||
As mentioned earlier, Unix provides the `fork()` system call as its primary process creation primitive. The `fork()` system call copies the address space of the calling process (the parent) to create a new process (the child).
|
||||
|
||||
xv6 Unix implements `fork()` by copying all data from the parent's pages into new pages allocated for the child. This is essentially the same approach that `dumbfork()` takes. The copying of the parent's address space into the child is the most expensive part of the `fork()` operation.
|
||||
|
||||
However, a call to `fork()` is frequently followed almost immediately by a call to `exec()` in the child process, which replaces the child's memory with a new program. This is what the the shell typically does, for example. In this case, the time spent copying the parent's address space is largely wasted, because the child process will use very little of its memory before calling `exec()`.
|
||||
|
||||
For this reason, later versions of Unix took advantage of virtual memory hardware to allow the parent and child to _share_ the memory mapped into their respective address spaces until one of the processes actually modifies it. This technique is known as _copy-on-write_. To do this, on `fork()` the kernel would copy the address space _mappings_ from the parent to the child instead of the contents of the mapped pages, and at the same time mark the now-shared pages read-only. When one of the two processes tries to write to one of these shared pages, the process takes a page fault. At this point, the Unix kernel realizes that the page was really a "virtual" or "copy-on-write" copy, and so it makes a new, private, writable copy of the page for the faulting process. In this way, the contents of individual pages aren't actually copied until they are actually written to. This optimization makes a `fork()` followed by an `exec()` in the child much cheaper: the child will probably only need to copy one page (the current page of its stack) before it calls `exec()`.
|
||||
|
||||
In the next piece of this lab, you will implement a "proper" Unix-like `fork()` with copy-on-write, as a user space library routine. Implementing `fork()` and copy-on-write support in user space has the benefit that the kernel remains much simpler and thus more likely to be correct. It also lets individual user-mode programs define their own semantics for `fork()`. A program that wants a slightly different implementation (for example, the expensive always-copy version like `dumbfork()`, or one in which the parent and child actually share memory afterward) can easily provide its own.
|
||||
|
||||
##### User-level page fault handling
|
||||
|
||||
A user-level copy-on-write `fork()` needs to know about page faults on write-protected pages, so that's what you'll implement first. Copy-on-write is only one of many possible uses for user-level page fault handling.
|
||||
|
||||
It's common to set up an address space so that page faults indicate when some action needs to take place. For example, most Unix kernels initially map only a single page in a new process's stack region, and allocate and map additional stack pages later "on demand" as the process's stack consumption increases and causes page faults on stack addresses that are not yet mapped. A typical Unix kernel must keep track of what action to take when a page fault occurs in each region of a process's space. For example, a fault in the stack region will typically allocate and map new page of physical memory. A fault in the program's BSS region will typically allocate a new page, fill it with zeroes, and map it. In systems with demand-paged executables, a fault in the text region will read the corresponding page of the binary off of disk and then map it.
|
||||
|
||||
This is a lot of information for the kernel to keep track of. Instead of taking the traditional Unix approach, you will decide what to do about each page fault in user space, where bugs are less damaging. This design has the added benefit of allowing programs great flexibility in defining their memory regions; you'll use user-level page fault handling later for mapping and accessing files on a disk-based file system.
|
||||
|
||||
###### Setting the Page Fault Handler
|
||||
|
||||
In order to handle its own page faults, a user environment will need to register a _page fault handler entrypoint_ with the JOS kernel. The user environment registers its page fault entrypoint via the new `sys_env_set_pgfault_upcall` system call. We have added a new member to the `Env` structure, `env_pgfault_upcall`, to record this information.
|
||||
|
||||
```
|
||||
Exercise 8. Implement the `sys_env_set_pgfault_upcall` system call. Be sure to enable permission checking when looking up the environment ID of the target environment, since this is a "dangerous" system call.
|
||||
```
|
||||
|
||||
###### Normal and Exception Stacks in User Environments
|
||||
|
||||
During normal execution, a user environment in JOS will run on the _normal_ user stack: its `ESP` register starts out pointing at `USTACKTOP`, and the stack data it pushes resides on the page between `USTACKTOP-PGSIZE` and `USTACKTOP-1` inclusive. When a page fault occurs in user mode, however, the kernel will restart the user environment running a designated user-level page fault handler on a different stack, namely the _user exception_ stack. In essence, we will make the JOS kernel implement automatic "stack switching" on behalf of the user environment, in much the same way that the x86 _processor_ already implements stack switching on behalf of JOS when transferring from user mode to kernel mode!
|
||||
|
||||
The JOS user exception stack is also one page in size, and its top is defined to be at virtual address `UXSTACKTOP`, so the valid bytes of the user exception stack are from `UXSTACKTOP-PGSIZE` through `UXSTACKTOP-1` inclusive. While running on this exception stack, the user-level page fault handler can use JOS's regular system calls to map new pages or adjust mappings so as to fix whatever problem originally caused the page fault. Then the user-level page fault handler returns, via an assembly language stub, to the faulting code on the original stack.
|
||||
|
||||
Each user environment that wants to support user-level page fault handling will need to allocate memory for its own exception stack, using the `sys_page_alloc()` system call introduced in part A.
|
||||
|
||||
###### Invoking the User Page Fault Handler
|
||||
|
||||
You will now need to change the page fault handling code in `kern/trap.c` to handle page faults from user mode as follows. We will call the state of the user environment at the time of the fault the _trap-time_ state.
|
||||
|
||||
If there is no page fault handler registered, the JOS kernel destroys the user environment with a message as before. Otherwise, the kernel sets up a trap frame on the exception stack that looks like a `struct UTrapframe` from `inc/trap.h`:
|
||||
|
||||
```
|
||||
<-- UXSTACKTOP
|
||||
trap-time esp
|
||||
trap-time eflags
|
||||
trap-time eip
|
||||
trap-time eax start of struct PushRegs
|
||||
trap-time ecx
|
||||
trap-time edx
|
||||
trap-time ebx
|
||||
trap-time esp
|
||||
trap-time ebp
|
||||
trap-time esi
|
||||
trap-time edi end of struct PushRegs
|
||||
tf_err (error code)
|
||||
fault_va <-- %esp when handler is run
|
||||
|
||||
```
|
||||
|
||||
The kernel then arranges for the user environment to resume execution with the page fault handler running on the exception stack with this stack frame; you must figure out how to make this happen. The `fault_va` is the virtual address that caused the page fault.
|
||||
|
||||
If the user environment is _already_ running on the user exception stack when an exception occurs, then the page fault handler itself has faulted. In this case, you should start the new stack frame just under the current `tf->tf_esp` rather than at `UXSTACKTOP`. You should first push an empty 32-bit word, then a `struct UTrapframe`.
|
||||
|
||||
To test whether `tf->tf_esp` is already on the user exception stack, check whether it is in the range between `UXSTACKTOP-PGSIZE` and `UXSTACKTOP-1`, inclusive.
|
||||
|
||||
```
|
||||
Exercise 9. Implement the code in `page_fault_handler` in `kern/trap.c` required to dispatch page faults to the user-mode handler. Be sure to take appropriate precautions when writing into the exception stack. (What happens if the user environment runs out of space on the exception stack?)
|
||||
```
|
||||
|
||||
###### User-mode Page Fault Entrypoint
|
||||
|
||||
Next, you need to implement the assembly routine that will take care of calling the C page fault handler and resume execution at the original faulting instruction. This assembly routine is the handler that will be registered with the kernel using `sys_env_set_pgfault_upcall()`.
|
||||
|
||||
```
|
||||
Exercise 10. Implement the `_pgfault_upcall` routine in `lib/pfentry.S`. The interesting part is returning to the original point in the user code that caused the page fault. You'll return directly there, without going back through the kernel. The hard part is simultaneously switching stacks and re-loading the EIP.
|
||||
```
|
||||
|
||||
Finally, you need to implement the C user library side of the user-level page fault handling mechanism.
|
||||
|
||||
```
|
||||
Exercise 11. Finish `set_pgfault_handler()` in `lib/pgfault.c`.
|
||||
```
|
||||
|
||||
###### Testing
|
||||
|
||||
Run `user/faultread` (make run-faultread). You should see:
|
||||
|
||||
```
|
||||
...
|
||||
[00000000] new env 00001000
|
||||
[00001000] user fault va 00000000 ip 0080003a
|
||||
TRAP frame ...
|
||||
[00001000] free env 00001000
|
||||
```
|
||||
|
||||
Run `user/faultdie`. You should see:
|
||||
|
||||
```
|
||||
...
|
||||
[00000000] new env 00001000
|
||||
i faulted at va deadbeef, err 6
|
||||
[00001000] exiting gracefully
|
||||
[00001000] free env 00001000
|
||||
```
|
||||
|
||||
Run `user/faultalloc`. You should see:
|
||||
|
||||
```
|
||||
...
|
||||
[00000000] new env 00001000
|
||||
fault deadbeef
|
||||
this string was faulted in at deadbeef
|
||||
fault cafebffe
|
||||
fault cafec000
|
||||
this string was faulted in at cafebffe
|
||||
[00001000] exiting gracefully
|
||||
[00001000] free env 00001000
|
||||
```
|
||||
|
||||
If you see only the first "this string" line, it means you are not handling recursive page faults properly.
|
||||
|
||||
Run `user/faultallocbad`. You should see:
|
||||
|
||||
```
|
||||
...
|
||||
[00000000] new env 00001000
|
||||
[00001000] user_mem_check assertion failure for va deadbeef
|
||||
[00001000] free env 00001000
|
||||
```
|
||||
|
||||
Make sure you understand why `user/faultalloc` and `user/faultallocbad` behave differently.
|
||||
|
||||
```
|
||||
Challenge! Extend your kernel so that not only page faults, but _all_ types of processor exceptions that code running in user space can generate, can be redirected to a user-mode exception handler. Write user-mode test programs to test user-mode handling of various exceptions such as divide-by-zero, general protection fault, and illegal opcode.
|
||||
```
|
||||
|
||||
##### Implementing Copy-on-Write Fork
|
||||
|
||||
You now have the kernel facilities to implement copy-on-write `fork()` entirely in user space.
|
||||
|
||||
We have provided a skeleton for your `fork()` in `lib/fork.c`. Like `dumbfork()`, `fork()` should create a new environment, then scan through the parent environment's entire address space and set up corresponding page mappings in the child. The key difference is that, while `dumbfork()` copied _pages_ , `fork()` will initially only copy page _mappings_. `fork()` will copy each page only when one of the environments tries to write it.
|
||||
|
||||
The basic control flow for `fork()` is as follows:
|
||||
|
||||
1. The parent installs `pgfault()` as the C-level page fault handler, using the `set_pgfault_handler()` function you implemented above.
|
||||
|
||||
2. The parent calls `sys_exofork()` to create a child environment.
|
||||
|
||||
3. For each writable or copy-on-write page in its address space below UTOP, the parent calls `duppage`, which should map the page copy-on-write into the address space of the child and then _remap_ the page copy-on-write in its own address space. [ Note: The ordering here (i.e., marking a page as COW in the child before marking it in the parent) actually matters! Can you see why? Try to think of a specific case where reversing the order could cause trouble. ] `duppage` sets both PTEs so that the page is not writeable, and to contain `PTE_COW` in the "avail" field to distinguish copy-on-write pages from genuine read-only pages.
|
||||
|
||||
The exception stack is _not_ remapped this way, however. Instead you need to allocate a fresh page in the child for the exception stack. Since the page fault handler will be doing the actual copying and the page fault handler runs on the exception stack, the exception stack cannot be made copy-on-write: who would copy it?
|
||||
|
||||
`fork()` also needs to handle pages that are present, but not writable or copy-on-write.
|
||||
|
||||
4. The parent sets the user page fault entrypoint for the child to look like its own.
|
||||
|
||||
5. The child is now ready to run, so the parent marks it runnable.
|
||||
|
||||
|
||||
|
||||
|
||||
Each time one of the environments writes a copy-on-write page that it hasn't yet written, it will take a page fault. Here's the control flow for the user page fault handler:
|
||||
|
||||
1. The kernel propagates the page fault to `_pgfault_upcall`, which calls `fork()`'s `pgfault()` handler.
|
||||
2. `pgfault()` checks that the fault is a write (check for `FEC_WR` in the error code) and that the PTE for the page is marked `PTE_COW`. If not, panic.
|
||||
3. `pgfault()` allocates a new page mapped at a temporary location and copies the contents of the faulting page into it. Then the fault handler maps the new page at the appropriate address with read/write permissions, in place of the old read-only mapping.
|
||||
|
||||
|
||||
|
||||
The user-level `lib/fork.c` code must consult the environment's page tables for several of the operations above (e.g., that the PTE for a page is marked `PTE_COW`). The kernel maps the environment's page tables at `UVPT` exactly for this purpose. It uses a [clever mapping trick][1] to make it to make it easy to lookup PTEs for user code. `lib/entry.S` sets up `uvpt` and `uvpd` so that you can easily lookup page-table information in `lib/fork.c`.
|
||||
|
||||
``````
|
||||
Exercise 12. Implement `fork`, `duppage` and `pgfault` in `lib/fork.c`.
|
||||
|
||||
Test your code with the `forktree` program. It should produce the following messages, with interspersed 'new env', 'free env', and 'exiting gracefully' messages. The messages may not appear in this order, and the environment IDs may be different.
|
||||
|
||||
1000: I am ''
|
||||
1001: I am '0'
|
||||
2000: I am '00'
|
||||
2001: I am '000'
|
||||
1002: I am '1'
|
||||
3000: I am '11'
|
||||
3001: I am '10'
|
||||
4000: I am '100'
|
||||
1003: I am '01'
|
||||
5000: I am '010'
|
||||
4001: I am '011'
|
||||
2002: I am '110'
|
||||
1004: I am '001'
|
||||
1005: I am '111'
|
||||
1006: I am '101'
|
||||
```
|
||||
|
||||
```
|
||||
Challenge! Implement a shared-memory `fork()` called `sfork()`. This version should have the parent and child _share_ all their memory pages (so writes in one environment appear in the other) except for pages in the stack area, which should be treated in the usual copy-on-write manner. Modify `user/forktree.c` to use `sfork()` instead of regular `fork()`. Also, once you have finished implementing IPC in part C, use your `sfork()` to run `user/pingpongs`. You will have to find a new way to provide the functionality of the global `thisenv` pointer.
|
||||
```
|
||||
|
||||
```
|
||||
Challenge! Your implementation of `fork` makes a huge number of system calls. On the x86, switching into the kernel using interrupts has non-trivial cost. Augment the system call interface so that it is possible to send a batch of system calls at once. Then change `fork` to use this interface.
|
||||
|
||||
How much faster is your new `fork`?
|
||||
|
||||
You can answer this (roughly) by using analytical arguments to estimate how much of an improvement batching system calls will make to the performance of your `fork`: How expensive is an `int 0x30` instruction? How many times do you execute `int 0x30` in your `fork`? Is accessing the `TSS` stack switch also expensive? And so on...
|
||||
|
||||
Alternatively, you can boot your kernel on real hardware and _really_ benchmark your code. See the `RDTSC` (read time-stamp counter) instruction, defined in the IA32 manual, which counts the number of clock cycles that have elapsed since the last processor reset. QEMU doesn't emulate this instruction faithfully (it can either count the number of virtual instructions executed or use the host TSC, neither of which reflects the number of cycles a real CPU would require).
|
||||
```
|
||||
|
||||
This ends part B. Make sure you pass all of the Part B tests when you run make grade. As usual, you can hand in your submission with make handin.
|
||||
|
||||
#### Part C: Preemptive Multitasking and Inter-Process communication (IPC)
|
||||
|
||||
In the final part of lab 4 you will modify the kernel to preempt uncooperative environments and to allow environments to pass messages to each other explicitly.
|
||||
|
||||
##### Clock Interrupts and Preemption
|
||||
|
||||
Run the `user/spin` test program. This test program forks off a child environment, which simply spins forever in a tight loop once it receives control of the CPU. Neither the parent environment nor the kernel ever regains the CPU. This is obviously not an ideal situation in terms of protecting the system from bugs or malicious code in user-mode environments, because any user-mode environment can bring the whole system to a halt simply by getting into an infinite loop and never giving back the CPU. In order to allow the kernel to _preempt_ a running environment, forcefully retaking control of the CPU from it, we must extend the JOS kernel to support external hardware interrupts from the clock hardware.
|
||||
|
||||
###### Interrupt discipline
|
||||
|
||||
External interrupts (i.e., device interrupts) are referred to as IRQs. There are 16 possible IRQs, numbered 0 through 15. The mapping from IRQ number to IDT entry is not fixed. `pic_init` in `picirq.c` maps IRQs 0-15 to IDT entries `IRQ_OFFSET` through `IRQ_OFFSET+15`.
|
||||
|
||||
In `inc/trap.h`, `IRQ_OFFSET` is defined to be decimal 32. Thus the IDT entries 32-47 correspond to the IRQs 0-15. For example, the clock interrupt is IRQ 0. Thus, IDT[IRQ_OFFSET+0] (i.e., IDT[32]) contains the address of the clock's interrupt handler routine in the kernel. This `IRQ_OFFSET` is chosen so that the device interrupts do not overlap with the processor exceptions, which could obviously cause confusion. (In fact, in the early days of PCs running MS-DOS, the `IRQ_OFFSET` effectively _was_ zero, which indeed caused massive confusion between handling hardware interrupts and handling processor exceptions!)
|
||||
|
||||
In JOS, we make a key simplification compared to xv6 Unix. External device interrupts are _always_ disabled when in the kernel (and, like xv6, enabled when in user space). External interrupts are controlled by the `FL_IF` flag bit of the `%eflags` register (see `inc/mmu.h`). When this bit is set, external interrupts are enabled. While the bit can be modified in several ways, because of our simplification, we will handle it solely through the process of saving and restoring `%eflags` register as we enter and leave user mode.
|
||||
|
||||
You will have to ensure that the `FL_IF` flag is set in user environments when they run so that when an interrupt arrives, it gets passed through to the processor and handled by your interrupt code. Otherwise, interrupts are _masked_ , or ignored until interrupts are re-enabled. We masked interrupts with the very first instruction of the bootloader, and so far we have never gotten around to re-enabling them.
|
||||
|
||||
```
|
||||
Exercise 13. Modify `kern/trapentry.S` and `kern/trap.c` to initialize the appropriate entries in the IDT and provide handlers for IRQs 0 through 15. Then modify the code in `env_alloc()` in `kern/env.c` to ensure that user environments are always run with interrupts enabled.
|
||||
|
||||
Also uncomment the `sti` instruction in `sched_halt()` so that idle CPUs unmask interrupts.
|
||||
|
||||
The processor never pushes an error code when invoking a hardware interrupt handler. You might want to re-read section 9.2 of the [80386 Reference Manual][2], or section 5.8 of the [IA-32 Intel Architecture Software Developer's Manual, Volume 3][3], at this time.
|
||||
|
||||
After doing this exercise, if you run your kernel with any test program that runs for a non-trivial length of time (e.g., `spin`), you should see the kernel print trap frames for hardware interrupts. While interrupts are now enabled in the processor, JOS isn't yet handling them, so you should see it misattribute each interrupt to the currently running user environment and destroy it. Eventually it should run out of environments to destroy and drop into the monitor.
|
||||
```
|
||||
|
||||
###### Handling Clock Interrupts
|
||||
|
||||
In the `user/spin` program, after the child environment was first run, it just spun in a loop, and the kernel never got control back. We need to program the hardware to generate clock interrupts periodically, which will force control back to the kernel where we can switch control to a different user environment.
|
||||
|
||||
The calls to `lapic_init` and `pic_init` (from `i386_init` in `init.c`), which we have written for you, set up the clock and the interrupt controller to generate interrupts. You now need to write the code to handle these interrupts.
|
||||
|
||||
```
|
||||
Exercise 14. Modify the kernel's `trap_dispatch()` function so that it calls `sched_yield()` to find and run a different environment whenever a clock interrupt takes place.
|
||||
|
||||
You should now be able to get the `user/spin` test to work: the parent environment should fork off the child, `sys_yield()` to it a couple times but in each case regain control of the CPU after one time slice, and finally kill the child environment and terminate gracefully.
|
||||
```
|
||||
|
||||
This is a great time to do some _regression testing_. Make sure that you haven't broken any earlier part of that lab that used to work (e.g. `forktree`) by enabling interrupts. Also, try running with multiple CPUs using make CPUS=2 _target_. You should also be able to pass `stresssched` now. Run make grade to see for sure. You should now get a total score of 65/80 points on this lab.
|
||||
|
||||
##### Inter-Process communication (IPC)
|
||||
|
||||
(Technically in JOS this is "inter-environment communication" or "IEC", but everyone else calls it IPC, so we'll use the standard term.)
|
||||
|
||||
We've been focusing on the isolation aspects of the operating system, the ways it provides the illusion that each program has a machine all to itself. Another important service of an operating system is to allow programs to communicate with each other when they want to. It can be quite powerful to let programs interact with other programs. The Unix pipe model is the canonical example.
|
||||
|
||||
There are many models for interprocess communication. Even today there are still debates about which models are best. We won't get into that debate. Instead, we'll implement a simple IPC mechanism and then try it out.
|
||||
|
||||
###### IPC in JOS
|
||||
|
||||
You will implement a few additional JOS kernel system calls that collectively provide a simple interprocess communication mechanism. You will implement two system calls, `sys_ipc_recv` and `sys_ipc_try_send`. Then you will implement two library wrappers `ipc_recv` and `ipc_send`.
|
||||
|
||||
The "messages" that user environments can send to each other using JOS's IPC mechanism consist of two components: a single 32-bit value, and optionally a single page mapping. Allowing environments to pass page mappings in messages provides an efficient way to transfer more data than will fit into a single 32-bit integer, and also allows environments to set up shared memory arrangements easily.
|
||||
|
||||
###### Sending and Receiving Messages
|
||||
|
||||
To receive a message, an environment calls `sys_ipc_recv`. This system call de-schedules the current environment and does not run it again until a message has been received. When an environment is waiting to receive a message, _any_ other environment can send it a message - not just a particular environment, and not just environments that have a parent/child arrangement with the receiving environment. In other words, the permission checking that you implemented in Part A will not apply to IPC, because the IPC system calls are carefully designed so as to be "safe": an environment cannot cause another environment to malfunction simply by sending it messages (unless the target environment is also buggy).
|
||||
|
||||
To try to send a value, an environment calls `sys_ipc_try_send` with both the receiver's environment id and the value to be sent. If the named environment is actually receiving (it has called `sys_ipc_recv` and not gotten a value yet), then the send delivers the message and returns 0. Otherwise the send returns `-E_IPC_NOT_RECV` to indicate that the target environment is not currently expecting to receive a value.
|
||||
|
||||
A library function `ipc_recv` in user space will take care of calling `sys_ipc_recv` and then looking up the information about the received values in the current environment's `struct Env`.
|
||||
|
||||
Similarly, a library function `ipc_send` will take care of repeatedly calling `sys_ipc_try_send` until the send succeeds.
|
||||
|
||||
###### Transferring Pages
|
||||
|
||||
When an environment calls `sys_ipc_recv` with a valid `dstva` parameter (below `UTOP`), the environment is stating that it is willing to receive a page mapping. If the sender sends a page, then that page should be mapped at `dstva` in the receiver's address space. If the receiver already had a page mapped at `dstva`, then that previous page is unmapped.
|
||||
|
||||
When an environment calls `sys_ipc_try_send` with a valid `srcva` (below `UTOP`), it means the sender wants to send the page currently mapped at `srcva` to the receiver, with permissions `perm`. After a successful IPC, the sender keeps its original mapping for the page at `srcva` in its address space, but the receiver also obtains a mapping for this same physical page at the `dstva` originally specified by the receiver, in the receiver's address space. As a result this page becomes shared between the sender and receiver.
|
||||
|
||||
If either the sender or the receiver does not indicate that a page should be transferred, then no page is transferred. After any IPC the kernel sets the new field `env_ipc_perm` in the receiver's `Env` structure to the permissions of the page received, or zero if no page was received.
|
||||
|
||||
###### Implementing IPC
|
||||
|
||||
```
|
||||
Exercise 15. Implement `sys_ipc_recv` and `sys_ipc_try_send` in `kern/syscall.c`. Read the comments on both before implementing them, since they have to work together. When you call `envid2env` in these routines, you should set the `checkperm` flag to 0, meaning that any environment is allowed to send IPC messages to any other environment, and the kernel does no special permission checking other than verifying that the target envid is valid.
|
||||
|
||||
Then implement the `ipc_recv` and `ipc_send` functions in `lib/ipc.c`.
|
||||
|
||||
Use the `user/pingpong` and `user/primes` functions to test your IPC mechanism. `user/primes` will generate for each prime number a new environment until JOS runs out of environments. You might find it interesting to read `user/primes.c` to see all the forking and IPC going on behind the scenes.
|
||||
```
|
||||
|
||||
```
|
||||
Challenge! Why does `ipc_send` have to loop? Change the system call interface so it doesn't have to. Make sure you can handle multiple environments trying to send to one environment at the same time.
|
||||
```
|
||||
|
||||
```
|
||||
Challenge! The prime sieve is only one neat use of message passing between a large number of concurrent programs. Read C. A. R. Hoare, ``Communicating Sequential Processes,'' _Communications of the ACM_ 21(8) (August 1978), 666-667, and implement the matrix multiplication example.
|
||||
```
|
||||
|
||||
```
|
||||
Challenge! One of the most impressive examples of the power of message passing is Doug McIlroy's power series calculator, described in [M. Douglas McIlroy, ``Squinting at Power Series,'' _Software--Practice and Experience_ , 20(7) (July 1990), 661-683][4]. Implement his power series calculator and compute the power series for _sin_ ( _x_ + _x_ ^3).
|
||||
```
|
||||
|
||||
```
|
||||
Challenge! Make JOS's IPC mechanism more efficient by applying some of the techniques from Liedtke's paper, [Improving IPC by Kernel Design][5], or any other tricks you may think of. Feel free to modify the kernel's system call API for this purpose, as long as your code is backwards compatible with what our grading scripts expect.
|
||||
```
|
||||
|
||||
**This ends part C.** Make sure you pass all of the make grade tests and don't forget to write up your answers to the questions and a description of your challenge exercise solution in `answers-lab4.txt`.
|
||||
|
||||
Before handing in, use git status and git diff to examine your changes and don't forget to git add answers-lab4.txt. When you're ready, commit your changes with git commit -am 'my solutions to lab 4', then make handin and follow the directions.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://pdos.csail.mit.edu/6.828/2018/labs/lab4/
|
||||
|
||||
作者：[csail.mit][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://pdos.csail.mit.edu
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://pdos.csail.mit.edu/6.828/2018/labs/lab4/uvpt.html
|
||||
[2]: https://pdos.csail.mit.edu/6.828/2018/labs/readings/i386/toc.htm
|
||||
[3]: https://pdos.csail.mit.edu/6.828/2018/labs/readings/ia32/IA32-3A.pdf
|
||||
[4]: https://swtch.com/~rsc/thread/squint.pdf
|
||||
[5]: http://dl.acm.org/citation.cfm?id=168633
|
||||
@ -0,0 +1,131 @@
|
||||
How to Check HP iLO Firmware Version from Linux Command Line
|
||||
======
|
||||
There are many utilities are available in Linux to get a [hardware information][1].
|
||||
|
||||
Each tool has their own unique feature which help us to gather the required information.
|
||||
|
||||
We have already wrote many articles about this, the hardware tools are Dmidecode, hwinfo, lshw, inxi, lspci, lssci, lsusb, lsblk, neofetch, screenfetch, etc.,
|
||||
|
||||
Today we are going to discuss about the same topic. I will tell you, how to check HP iLO firmware version through Linux command line.
|
||||
|
||||
Also read a following articles which is related to Linux hardware.
|
||||
|
||||
**Suggested Read :**
|
||||
**(#)** [LSHW (Hardware Lister) – A Nifty Tool To Get A Hardware Information On Linux][2]
|
||||
**(#)** [inxi – A Great Tool to Check Hardware Information on Linux][3]
|
||||
**(#)** [Dmidecode – Easy Way To Get Linux System Hardware Information][4]
|
||||
**(#)** [Neofetch – Shows Linux System Information With ASCII Distribution Logo][5]
|
||||
**(#)** [ScreenFetch – Fetch Linux System Information on Terminal with Distribution ASCII art logo][6]
|
||||
**(#)** [16 Methods To Check If A Linux System Is Physical or Virtual Machine][7]
|
||||
**(#)** [hwinfo (Hardware Info) – A Nifty Tool To Detect System Hardware Information On Linux][8]
|
||||
**(#)** [How To Find WWN, WWNN and WWPN Number Of HBA Card In Linux][9]
|
||||
**(#)** [How To Check System Hardware Manufacturer, Model And Serial Number In Linux][1]
|
||||
**(#)** [How To Use lspci, lsscsi, lsusb, And lsblk To Get Linux System Devices Information][10]
|
||||
|
||||
### What is iLO?
|
||||
|
||||
iLO stands for Integrated Lights-Out is a proprietary embedded server management technology by Hewlett-Packard which provides out-of-band management facilities.
|
||||
|
||||
I can say this in simple term, it’s a dedicated device management channel which allow users to manage and monitor the device remotely regardless of whether the machine is powered on, or whether an operating system is installed or functional.
|
||||
|
||||
It allows a system administrator to monitor all devices such as CPU, RAM, Hardware RAID, fan speed, power voltages, chassis intrusion, firmware (BIOS or UEFI), also manage remote terminals (KVM over IP), remote reboot, shutdown, powering on, etc.
|
||||
|
||||
The below list of lights out management (LOM) technology offered by other vendors.
|
||||
|
||||
* **`iLO:`** Integrated Lights-Out by HP
|
||||
* **`IMM:`** Integrated Management Module by IBM
|
||||
* **`iDRAC:`** Integrated Dell Remote Access Controllers by Dell
|
||||
* **`IPMI:`** Intelligent Platform Management Interface – General Standard, it’s used on Supermicro hardware
|
||||
* **`AMT:`** Intel Active Management Technology by Intel
|
||||
* **`CIMC:`** Cisco Integrated Management Controller by Cisco
|
||||
|
||||
|
||||
|
||||
The below table will give the details about iLO version and supported hardware’s.
|
||||
|
||||
* **`iLO:`** ProLiant G2, G3, G4, and G6 servers, model numbers under 300
|
||||
* **`iLO 2:`** ProLiant G5 and G6 servers, model numbers 300 and higher
|
||||
* **`iLO 3:`** ProLiant G7 servers
|
||||
* **`iLO 4:`** ProLiant Gen8 and Gen9 servers
|
||||
* **`iLO 5:`** ProLiant Gen10 servers
|
||||
|
||||
|
||||
|
||||
There are three easy ways to check HP iLO firmware version in Linux, Here we are going to show you one by one.
|
||||
|
||||
### Method-1: Using Dmidcode Command
|
||||
|
||||
[Dmidecode][4] is a tool which reads a computer’s DMI (stands for Desktop Management Interface) (some say SMBIOS – stands for System Management BIOS) table contents and display system hardware information in a human-readable format.
|
||||
|
||||
This table contains a description of the system’s hardware components, as well as other useful information such as serial number, Manufacturer information, Release Date, and BIOS revision, etc,.,
|
||||
|
||||
The DMI table doesn’t only describe what the system is currently made of, it also can report the possible evolution’s (such as the fastest supported CPU or the maximal amount of memory supported). This will help you to analyze your hardware capability like whether it’s support latest application version or not?
|
||||
|
||||
As you run it, dmidecode will try to locate the DMI table. If it succeeds, it will then parse this table and display a list of records which you expect.
|
||||
|
||||
First, learn about DMI Types and its keywords, so that we can play nicely without any trouble otherwise we can’t.
|
||||
|
||||
```
|
||||
# dmidecode | grep "Firmware Revision"
|
||||
Firmware Revision: 2.40
|
||||
```
|
||||
|
||||
### Method-2: Using HPONCFG Utility
|
||||
|
||||
HPONCFG is an online configuration tool used to set up and reconfigure iLO without requiring a reboot of the server operating system. The utility runs in a command-line mode and must be executed from an operating system command line on the local server. HPONCFG enables you to initially configure features exposed through the RBSU or iLO.
|
||||
|
||||
Before using HPONCFG, the iLO Management Interface Driver must be loaded on the server. HPONCFG displays a warning if the driver is not installed.
|
||||
|
||||
To install this, visit the [HP website][11] and get the latest hponcfg package by searching the following keyword (sample search key word for iLO 4 “HPE Integrated Lights-Out 4 (iLO 4)”). In that you need to click “HP Lights-Out Online Configuration Utility for Linux (AMD64/EM64T)” and download the package.
|
||||
|
||||
```
|
||||
# rpm -ivh /tmp/hponcfg-5.3.0-0.x86_64.rpm
|
||||
```
|
||||
|
||||
Use hponcfg command to get the information.
|
||||
|
||||
```
|
||||
# hponcfg | grep Firmware
|
||||
Firmware Revision = 2.40 Device type = iLO 4 Driver name = hpilo
|
||||
```
|
||||
|
||||
### Method-3: Using CURL Command
|
||||
|
||||
We can use cURL command to get some of the information in XML format, for HP iLO, iLO 2, iLO 3, iLO 4 and iLO 5.
|
||||
|
||||
Using cURL command we can get the iLO firmware version without to login to the server or console.
|
||||
|
||||
Make sure you have to use right iLO management IP instead of us to get the details. I have removed all the unnecessary details from the below output for better clarification.
|
||||
|
||||
```
|
||||
# curl -k https://10.2.0.101/xmldata?item=All
|
||||
|
||||
ProLiant DL380p G8
|
||||
Integrated Lights-Out 4 (iLO 4)
|
||||
2.40
|
||||
```
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.2daygeek.com/how-to-check-hp-ilo-firmware-version-from-linux-command-line/
|
||||
|
||||
作者：[Prakash Subramanian][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://www.2daygeek.com/author/prakash/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://www.2daygeek.com/how-to-check-system-hardware-manufacturer-model-and-serial-number-in-linux/
|
||||
[2]: https://www.2daygeek.com/lshw-find-check-system-hardware-information-details-linux/
|
||||
[3]: https://www.2daygeek.com/inxi-system-hardware-information-on-linux/
|
||||
[4]: https://www.2daygeek.com/dmidecode-get-print-display-check-linux-system-hardware-information/
|
||||
[5]: https://www.2daygeek.com/neofetch-display-linux-systems-information-ascii-distribution-logo-terminal/
|
||||
[6]: https://www.2daygeek.com/install-screenfetch-to-fetch-linux-system-information-on-terminal-with-distribution-ascii-art-logo/
|
||||
[7]: https://www.2daygeek.com/check-linux-system-physical-virtual-machine-virtualization-technology/
|
||||
[8]: https://www.2daygeek.com/hwinfo-check-display-detect-system-hardware-information-linux/
|
||||
[9]: https://www.2daygeek.com/how-to-find-wwn-wwnn-and-wwpn-number-of-hba-card-in-linux/
|
||||
[10]: https://www.2daygeek.com/check-system-hardware-devices-bus-information-lspci-lsscsi-lsusb-lsblk-linux/
|
||||
[11]: https://support.hpe.com/hpesc/public/home
|
||||
@ -1,3 +1,5 @@
|
||||
translating---geekpi
|
||||
|
||||
4 cool new projects to try in COPR for October 2018
|
||||
======
|
||||
|
||||
|
||||
@ -0,0 +1,100 @@
|
||||
FSSlc translating
|
||||
|
||||
How To Analyze And Explore The Contents Of Docker Images
|
||||
======
|
||||
|
||||
|
||||
As you may already know, a Docker container image is a lightweight, standalone, executable package of software that has everything required to run an application. That’s why container images are often used by developers for building and distributing applications. If you’re curious to know what is in a Docker image, this brief guide might help you. Today, we are going to learn to analyze and explore the contents of Docker images layer by layer using a tool named **“Dive”**. By analyzing a Docker image, we can discover possible duplicate files across the layers and remove them to reduce the size of the docker image. The Dive utility is not just a Docker Image analyzer, but also helps us to build one.
|
||||
|
||||
### Installing Dive
|
||||
|
||||
Get the latest version from the [**releases page**][1] and install it as shown below depending upon the distribution you use.
|
||||
|
||||
If you’re on **Debian** or **Ubuntu** , run the following commands to download and install it.
|
||||
|
||||
```
|
||||
$ wget https://github.com/wagoodman/dive/releases/download/v0.0.8/dive_0.0.8_linux_amd64.deb
|
||||
|
||||
$ sudo apt install ./dive_0.0.8_linux_amd64.deb
|
||||
```
|
||||
|
||||
**On RHEL/CentOS:**
|
||||
|
||||
```
|
||||
$ wget https://github.com/wagoodman/dive/releases/download/v0.0.8/dive_0.0.8_linux_amd64.rpm
|
||||
|
||||
$ sudo rpm -i dive_0.0.8_linux_amd64.rpm
|
||||
```
|
||||
|
||||
Dive can also installed using [**Linuxbrew**][2] package manager.
|
||||
|
||||
```
|
||||
$ brew tap wagoodman/dive
|
||||
|
||||
$ brew install dive
|
||||
```
|
||||
|
||||
For other installation methods, refer the project’s GitHub page given at the end of this guide.
|
||||
|
||||
### Analyze And Explore The Contents Of Docker Images
|
||||
|
||||
To analyze a Docker image, simply run dive command with Docker “Image ID”. You can get your Docker images’ IDs using “sudo docker images” command.
|
||||
|
||||
```
|
||||
$ sudo dive ea4c82dcd15a
|
||||
```
|
||||
|
||||
Here, **ea4c82dcd15a** is Docker image id.
|
||||
|
||||
The Dive command will quickly analyze the given Docker image and display its contents in the Terminal.
|
||||
|
||||
As you can see in the above screenshot, the layers of given docker image and its details, wasted space are shown in the left pane. On the right pane, the contents of each layer in the given Docker image. You can switch between the left and right pane using **Ctrl+SPACEBAR** key and **UP/DOWN** arrow keys to navigate through the directory tree.
|
||||
|
||||
The list of keyboard shortcuts to use “Dive”.
|
||||
|
||||
* **Ctrl+Spacebar** – Switch between left and right panes,
|
||||
* **Spacebar** – Expand/Collapse directory tree,
|
||||
* **Ctrl+A** – Show/hide added files,
|
||||
* **Ctrl+R** – Show/hide removed files,
|
||||
* **Ctrl+M** – Show/hide modified files,
|
||||
* **Ctrl+U** – Show/hide unmodified files,
|
||||
* **Ctrl+ L** – Show layer changes,
|
||||
* **Ctrl+A** – Show layer changes,
|
||||
* **Ctrl+/** – Filter files,
|
||||
* **Ctrl+C** – Exit.
|
||||
|
||||
|
||||
|
||||
In the above example, I have used “sudo” permission, because my Docker images are stored in **/var/lib/docker/** directory. If you have them on your $HOME directory or anywhere not owned “root” user, you need not to use “sudo”.
|
||||
|
||||
You can also build a Docker image and do an immediate analysis with one command: ``
|
||||
|
||||
```
|
||||
$ dive build -t <some-tag>
|
||||
```
|
||||
|
||||
Dive tool is still in beta stage, so there will be bugs. If you came across any bugs, report them in the project’s github page.
|
||||
|
||||
And, that’s all for today. You know now how to explore and analyze the contents of Docker container image and how to build it using Dive tool. Hope this helps.
|
||||
|
||||
More good stuffs to come. Stay tuned!
|
||||
|
||||
Cheers!
|
||||
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.ostechnix.com/how-to-analyze-and-explore-the-contents-of-docker-images/
|
||||
|
||||
作者：[SK][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://www.ostechnix.com/author/sk/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://github.com/wagoodman/dive/releases
|
||||
[2]: https://www.ostechnix.com/linuxbrew-common-package-manager-linux-mac-os-x/
|
||||
@ -0,0 +1,130 @@
|
||||
Podman: A more secure way to run containers
|
||||
======
|
||||
Podman uses a traditional fork/exec model (vs. a client/server model) for running containers.
|
||||
|
||||
|
||||
Before I get into the main topic of this article, [Podman][1] and containers, I need to get a little technical about the Linux audit feature.
|
||||
|
||||
### What is audit?
|
||||
|
||||
The Linux kernel has an interesting security feature called **audit**. It allows administrators to watch for security events on a system and have them logged to the audit.log, which can be stored locally or remotely on another machine to prevent a hacker from trying to cover his tracks.
|
||||
|
||||
The **/etc/shadow** file is a common security file to watch, since adding a record to it could allow an attacker to get return access to the system. Administrators want to know if any process modified the file. You can do this by executing the command:
|
||||
|
||||
```
|
||||
# auditctl -w /etc/shadow
|
||||
```
|
||||
|
||||
Now let's see what happens if I modify the /etc/shadow file:
|
||||
|
||||
```
|
||||
# touch /etc/shadow
|
||||
# ausearch -f /etc/shadow -i -ts recent
|
||||
|
||||
type=PROCTITLE msg=audit(10/10/2018 09:46:03.042:4108) : proctitle=touch /etc/shadow type=SYSCALL msg=audit(10/10/2018 09:46:03.042:4108) : arch=x86_64 syscall=openat success=yes exit=3 a0=0xffffff9c a1=0x7ffdb17f6704 a2=O_WRONLY|O_CREAT|O_NOCTTY| O_NONBLOCK a3=0x1b6 items=2 ppid=2712 pid=3727 auid=dwalsh uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=3 comm=touch exe=/usr/bin/touch subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)`
|
||||
```
|
||||
|
||||
There's a lot of information in the audit record, but I highlighted that it recorded that root modified the /etc/shadow file and the owner of the process' audit UID ( **auid** ) was **dwalsh**.
|
||||
|
||||
Did the kernel do that?
|
||||
|
||||
#### Tracking the login UID
|
||||
|
||||
**loginuid** , stored in **/proc/self/loginuid** , that is part of the proc struct of every process on the system. This field can be set only once; after it is set, the kernel will not allow any process to reset it.
|
||||
|
||||
There is a field called, stored in, that is part of the proc struct of every process on the system. This field can be set only once; after it is set, the kernel will not allow any process to reset it.
|
||||
|
||||
When I log into the system, the login program sets the loginuid field for my login process.
|
||||
|
||||
My UID, dwalsh, is 3267.
|
||||
|
||||
```
|
||||
$ cat /proc/self/loginuid
|
||||
3267
|
||||
```
|
||||
|
||||
Now, even if I become root, my login UID stays the same.
|
||||
|
||||
```
|
||||
$ sudo cat /proc/self/loginuid
|
||||
3267
|
||||
```
|
||||
|
||||
Note that every process that's forked and executed from the initial login process automatically inherits the loginuid. This is how the kernel knew that the person who logged was dwalsh.
|
||||
|
||||
### Containers
|
||||
|
||||
Now let's look at containers.
|
||||
|
||||
```
|
||||
sudo podman run fedora cat /proc/self/loginuid
|
||||
3267
|
||||
```
|
||||
|
||||
Even the container process retains my loginuid. Now let's try with Docker.
|
||||
|
||||
```
|
||||
sudo docker run fedora cat /proc/self/loginuid
|
||||
4294967295
|
||||
```
|
||||
|
||||
### Why the difference?
|
||||
|
||||
Podman uses a traditional fork/exec model for the container, so the container process is an offspring of the Podman process. Docker uses a client/server model. The **docker** command I executed is the Docker client tool, and it communicates with the Docker daemon via a client/server operation. Then the Docker daemon creates the container and handles communications of stdin/stdout back to the Docker client tool.
|
||||
|
||||
The default loginuid of processes (before their loginuid is set) is 4294967295. Since the container is an offspring of the Docker daemon and the Docker daemon is a child of the init system, we see that systemd, Docker daemon, and the container processes all have the same loginuid, 4294967295, which audit refers to as the unset audit UID.
|
||||
|
||||
```
|
||||
cat /proc/1/loginuid
|
||||
4294967295
|
||||
```
|
||||
|
||||
### How can this be abused?
|
||||
|
||||
Let's look at what would happen if a container process launched by Docker modifies the /etc/shadow file.
|
||||
|
||||
```
|
||||
$ sudo docker run --privileged -v /:/host fedora touch /host/etc/shadow
|
||||
$ sudo ausearch -f /etc/shadow -i type=PROCTITLE msg=audit(10/10/2018 10:27:20.055:4569) : proctitle=/usr/bin/coreutils --coreutils-prog-shebang=touch /usr/bin/touch /host/etc/shadow type=SYSCALL msg=audit(10/10/2018 10:27:20.055:4569) : arch=x86_64 syscall=openat success=yes exit=3 a0=0xffffff9c a1=0x7ffdb6973f50 a2=O_WRONLY|O_CREAT|O_NOCTTY| O_NONBLOCK a3=0x1b6 items=2 ppid=11863 pid=11882 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=touch exe=/usr/bin/coreutils subj=system_u:system_r:spc_t:s0 key=(null)
|
||||
```
|
||||
|
||||
In the Docker case, the auid is unset (4294967295); this means the security officer might know that a process modified the /etc/shadow file but the identity was lost.
|
||||
|
||||
If that attacker then removed the Docker container, there would be no trace on the system of who modified the /etc/shadow file.
|
||||
|
||||
Now let's look at the exact same scenario with Podman.
|
||||
|
||||
```
|
||||
$ sudo podman run --privileged -v /:/host fedora touch /host/etc/shadow
|
||||
$ sudo ausearch -f /etc/shadow -i type=PROCTITLE msg=audit(10/10/2018 10:23:41.659:4530) : proctitle=/usr/bin/coreutils --coreutils-prog-shebang=touch /usr/bin/touch /host/etc/shadow type=SYSCALL msg=audit(10/10/2018 10:23:41.659:4530) : arch=x86_64 syscall=openat success=yes exit=3 a0=0xffffff9c a1=0x7fffdffd0f34 a2=O_WRONLY|O_CREAT|O_NOCTTY| O_NONBLOCK a3=0x1b6 items=2 ppid=11671 pid=11683 auid=dwalsh uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=3 comm=touch exe=/usr/bin/coreutils subj=unconfined_u:system_r:spc_t:s0 key=(null)
|
||||
```
|
||||
|
||||
Everything is recorded correctly with Podman since it uses traditional fork/exec.
|
||||
|
||||
This was just a simple example of watching the /etc/shadow file, but the auditing system is very powerful for watching what processes do on a system. Using a fork/exec container runtime for launching containers (instead of a client/server container runtime) allows you to maintain better security through audit logging.
|
||||
|
||||
### Final thoughts
|
||||
|
||||
There are many other nice features about the fork/exec model versus the client/server model when launching containers. For example, systemd features include:
|
||||
|
||||
* **SD_NOTIFY:** If you put a Podman command into a systemd unit file, the container process can return notice up the stack through Podman that the service is ready to receive tasks. This is something that can't be done in client/server mode.
|
||||
* **Socket activation:** You can pass down connected sockets from systemd to Podman and onto the container process to use them. This is impossible in the client/server model.
|
||||
|
||||
|
||||
|
||||
The nicest feature, in my opinion, is **running Podman and containers as a non-root user**. This means you never have give a user root privileges on the host, while in the client/server model (like Docker employs), you must open a socket to a privileged daemon running as root to launch the containers. There you are at the mercy of the security mechanisms implemented in the daemon versus the security mechanisms implemented in the host operating systems—a dangerous proposition.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/10/podman-more-secure-way-run-containers
|
||||
|
||||
作者：[Daniel J Walsh][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/rhatdan
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://podman.io
|
||||
@ -0,0 +1,92 @@
|
||||
DevOps应聘者应该准备回答的20个问题
|
||||
======
|
||||
|
||||
|
||||
聘请一个不合适的人代价是很高的。根据Link人力资源的首席执行官Jörgen Sundberg的统计，招聘，雇佣一名新员工将会花费公司$240,000之多，当你进行了一次不合适的招聘：
|
||||
* 你失去了他们所知道的。
|
||||
* 你失去了他们认识的人
|
||||
* 你的团队将可能进入到一个组织发展的震荡阶段
|
||||
* 你的公司将会面临组织破裂的风险
|
||||
|
||||
当你失去一名员工的时候，你就像丢失了公司图谱中的一块。同样值得一提的是另一端的疼痛。应聘到一个错误工作岗位的员工会感受到很大的压力以及整个身心的不满意，甚至是健康问题。
|
||||
另外一方面，当你招聘到合适的人时，新的员工将会：
|
||||
* 丰富公司现有的文化，使你的组织成为一个更好的工作场所。研究表明一个积极的工作文化能够帮助驱动一个更长久的财务业绩，而且如果你在一个欢快的环境中工 作，你更有可能在生活中做的更好。
|
||||
* 热爱和你的组织在一起工作。当人们热爱他们所在做的，他们会趋向于做的更好。
|
||||
|
||||
招聘适合的或者加强现有的文化在DevOps和敏捷团多中是必不可少的。也就是说雇佣到一个能够鼓励积极合作的人，以便来自不同背景，有着不同目标和工作方式的团队能够在一起有效的工作。你新雇佣的员工因应该能够帮助团队合作来充分发挥放大他们的价值同时也能够增加员工的满意度以及平衡组织目标的冲突。他或者她应该能够通过明智的选择工具和工作流来促进你的组织，文化就是一切。
|
||||
|
||||
作为我们2017年11月发布的一篇文章，[DevOps的招聘经理应该准备回答的20个问题][4],这篇文章将会重点关注在如何招聘最适合的人。
|
||||
### 为什么招聘走错了方向
|
||||
很多公司现在在用的典型的雇佣策略是基于人才过剩的基础上：
|
||||
|
||||
* 职位公告栏。
|
||||
* 关注和所需才能符合的应聘者。
|
||||
* 尽可能找多的候选者。
|
||||
* 通过面试淘汰弱者。
|
||||
* 通过正式的面试淘汰更多的弱者。
|
||||
* 评估，投票，选择。
|
||||
* 渐渐接近补偿。
|
||||
|
||||
|
||||
|
||||
职位公告栏是有成千上万失业者人才过剩的经济大萧条时期发明的。在今天的求职市场上已经没有人才过剩了，然而我们仍然在使用基于此的招聘策略。
|
||||
|
||||
|
||||
### 雇佣最合适的人员：运用文化和情感
|
||||
在人才过剩雇佣策略背后的思想是去设计工作岗位然后将人员安排进去。
|
||||
相反，做相反的事情：寻找将会积极融入你的商业文化的人才，然后为他们寻找他们热爱的最合适的岗位。要想如此实现，你必须能够围绕他们热情为他们创造工作岗位。
|
||||
**谁正在寻找一份工作？** 根据一份2016年对美国50，000名开发者的调查显示，[85.7%的受访对象][5]要么对新的机会不感兴趣，要么对于寻找新工作没有积极性。在寻找工作的那部分中，有将近[28.3%的求职者][5]来自于朋友的推荐。如果你只是在那些在找工作的人中寻找人才，你将会错过高端的人才。
|
||||
**运用团队力量去发现和寻找潜力的雇员**。列如，戴安娜是你的团队中的一名开发者，她所提供的机会即使她已经从事编程很多年而且在期间已经结识了很多从事热爱他们所从事的工作的人。难道你不认为她所推荐的潜在员工在技能，知识和智慧上要比HR所寻找的要优秀吗？在要求戴安娜分享她同伴之前，通知她即将到来的使命任务，向她阐明你要雇佣潜在有探索精神的团队，描述在将来会需要的知识领域。
|
||||
**雇员想要什么？**一份来自千禧年，婴儿潮实时期出生的人的对比综合性研究显示，20% 的人所想要的是相同的：
|
||||
1. 对组织产生积极的影响
|
||||
2. 帮助解决社交或者环境上的挑战
|
||||
3. 和一群有动力的人一起工作
|
||||
|
||||
### 面试的挑战
|
||||
面试应该是招聘者和应聘者双方为了寻找最合适的人才进行的一次双方之间的对话。将面试聚焦在企业文化和情感对话两个问题上：这个应聘者将会丰富你的企业文化并且会热爱和你在一起工作吗？你能够在工作中帮他们取得成功吗？
|
||||
**对于招聘经理来说：** 每一次的面试都是你学习如何将自己的组织变得对未来的团队成员更有吸引力，并且每次积极的面试多都可能是你发现人才（即使你不会雇佣）的机会。每个人都将会记得积极有效的面试的经历。即使他们不会被雇佣，他们将会和他们的朋友谈论这次经历，你竟会得到一个被推荐的机会。这又很大的好处：如果你无法吸引到这个人才，你也将会从中学习吸取经验并且改善。
|
||||
**对面试者来说**：每次的面试都是你释放激情的机会
|
||||
|
||||
### 助你释放潜在雇员激情的20个问题
|
||||
1. 你热爱什么？
|
||||
2. “今天早晨我已经迫不及待的要去工作”你怎么看待这句话？
|
||||
3. 你曾经最快乐的是什么？
|
||||
4. 你曾经解决问题的最典型的例子是什么，你是如何解决的？
|
||||
5. 你如何看待配对学习？
|
||||
6. 你到达办公室和离开办公室心里最先想到的是什么？
|
||||
7. 你如果你有一次改变你之前或者现在的共工作的一件事的机会，将会是什么事？
|
||||
8. 当你在这工作的时候，你最兴奋去学习什么？
|
||||
9. 你的梦想是什么，你如何去实现？
|
||||
10. 你在学会如何去实现你的追求的时候想要或者需要什么？
|
||||
11. 你的价值观是什么？
|
||||
12. 你是如何坚守自己的价值观的？
|
||||
13. 平衡在你的生活中意味着什么？
|
||||
14. 你最引以为傲的工作交流能力是什么？为什么？
|
||||
15. 你最喜欢营造什么样的环境？
|
||||
16. 你喜欢别人怎样对待你？
|
||||
17. 你信任我们什么，如何验证？
|
||||
18. 告诉我们你在最近的一个项目中学习到什么？
|
||||
19. 我们还能知道你的其他方面的什么？
|
||||
20. 如果你正在雇佣我，你将会问我什么问题？
|
||||
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/3/questions-devops-employees-should-answer
|
||||
|
||||
作者：[Catherine Louis][a]
|
||||
译者：[FelixYFZ](https://github.com/FelixYFZ)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://opensource.com/users/catherinelouis
|
||||
[1]:https://www.shrm.org/resourcesandtools/hr-topics/employee-relations/pages/cost-of-bad-hires.aspx
|
||||
[2]:https://en.wikipedia.org/wiki/Tuckman%27s_stages_of_group_development
|
||||
[3]:http://www.forbes.com/sites/johnkotter/2011/02/10/does-corporate-culture-drive-financial-performance/
|
||||
[4]:https://opensource.com/article/17/11/inclusive-workforce-takes-work
|
||||
[5]:https://insights.stackoverflow.com/survey/2016#work-job-discovery
|
||||
[6]:https://research.hackerrank.com/developer-skills/2018/
|
||||
[7]:http://www-935.ibm.com/services/us/gbs/thoughtleadership/millennialworkplace/
|
||||
[8]:https://en.wikipedia.org/wiki/Emotional_intelligence
|
||||
@ -1,307 +0,0 @@
|
||||
重启和关闭 Linux 系统的 6 个终端命令
|
||||
======
|
||||
在 Linux 管理员的日程当中, 有很多需要执行的任务, 系统的重启和关闭就被包含其中.
|
||||
|
||||
对于 Linux 管理员来说, 重启和关闭系统是其诸多风险操作中的一例, 有时候, 由于某些原因, 这些操作可能无法挽回, 他们需要更多的时间来排查问题.
|
||||
|
||||
在 Linux 命令行模式下我们可以执行这些任务. 很多时候, 由于熟悉命令行, Linux 管理员更倾向于在命令行下完成这些任务.
|
||||
|
||||
重启和关闭系统的 Linux 命令并不多, 用户需要根据需要, 选择合适的命令来完成任务.
|
||||
|
||||
以下所有命令都有其自身特点, 并允许被 Linux 管理员使用.
|
||||
|
||||
**建议阅读 :**
|
||||
|
||||
**(#)** [查看系统/服务器正常运行时间的 11 个方法][1]
|
||||
|
||||
**(#)** [Tuptime 一款为 Linux 系统保存历史记录, 统计运行时间工具][2]
|
||||
|
||||
系统重启和关闭之始, 会通知所有已登录的用户和已注册的进程. 当然, 如果会造成冲突, 系统不会允许新的用户登入.
|
||||
|
||||
执行此类操作之前, 我建议您坚持复查, 因为您只能得到很少的提示来确保这一切顺利.
|
||||
|
||||
下面陈列了一些步骤.
|
||||
|
||||
* 确保您拥有一个可以处理故障的终端, 以防之后可能会发生的问题. VMWare 可以访问物理服务器的虚拟机, IPMI, iLO 和 iDRAC.
|
||||
* 您需要通过公司的流程, 申请修改或故障的执行权直到得到许可.
|
||||
* 为安全着想, 备份重要的配置文件, 并保存到其他服务器上.
|
||||
* 验证日志文件(提前检查)
|
||||
* 和相关团队交流, 比如数据库管理团队, 应用团队等.
|
||||
* 通知数据库和应用服务人员关闭服务, 并得到确定.
|
||||
* 使用适当的命令复盘操作, 验证工作.
|
||||
* 最后, 重启系统
|
||||
* 验证日志文件, 如果一切顺利, 执行下一步操作, 如果发现任何问题, 对症排查.
|
||||
* 无论是回退版本还是运行程序, 通知相关团队提出申请.
|
||||
* 对操作做适当守候, 并将预期的一切正常的反馈给团队
|
||||
|
||||
使用下列命令执行这项任务.
|
||||
|
||||
* **`shutdown 命令:`** shutdown 命令用来为中止, 重启或切断电源
|
||||
* **`halt 命令:`** halt 命令用来为中止, 重启或切断电源
|
||||
* **`poweroff 命令:`** poweroff 命令用来为中止, 重启或切断电源
|
||||
* **`reboot 命令:`** reboot 命令用来为中止, 重启或切断电源
|
||||
* **`init 命令:`** init(initialization 的简称) 是系统启动的第一个进程.
|
||||
* **`systemctl 命令:`** systemd 是 Linux 系统和服务器的管理程序.
|
||||
|
||||
|
||||
### 方案 - 1: 如何使用 Shutdown 命令关闭和重启 Linux 系统
|
||||
|
||||
shutdown 命令用户关闭或重启本地和远程的 Linux 设备. 它为高效完成作业提供多个选项. 如果使用了 time 参数, 系统关闭的 5 分钟之前, /run/nologin 文件会被创建, 以确保后续的登录会被拒绝.
|
||||
|
||||
通用语法如下
|
||||
|
||||
```
|
||||
# shutdown [OPTION] [TIME] [MESSAGE]
|
||||
|
||||
```
|
||||
|
||||
运行下面的命令来立即关闭 Linux 设备. 它会立刻杀死所有进程, 并关闭系统.
|
||||
|
||||
```
|
||||
# shutdown -h now
|
||||
|
||||
```
|
||||
|
||||
* **`-h:`** 如果不特指 -halt 选项, 这等价于 -poweroff 选项.
|
||||
|
||||
另外我们可以使用带有 `poweroff` 选项的 `shutdown` 命令来立即关闭设备.
|
||||
|
||||
```
|
||||
# shutdown --halt now
|
||||
或者
|
||||
# shutdown -H now
|
||||
|
||||
```
|
||||
|
||||
* **`-H, --halt:`** 停止设备运行
|
||||
|
||||
另外我们可以使用带有 `poweroff` 选项的 `shutdown` 命令来立即关闭设备.
|
||||
|
||||
```
|
||||
# shutdown --poweroff now
|
||||
或者
|
||||
# shutdown -P now
|
||||
|
||||
```
|
||||
|
||||
* **`-P, --poweroff:`** 切断电源 (默认).
|
||||
|
||||
运行以下命令立即关闭 Linux 设备. 它将会立即杀死所有的进程并关闭系统.
|
||||
|
||||
```
|
||||
# shutdown -h now
|
||||
|
||||
```
|
||||
|
||||
* **`-h:`** 如果不特指 -halt 选项, 这等价于 -poweroff 选项.
|
||||
|
||||
如果您没有使用 time 选项运行下面的命令, 它将会在一分钟后执行给出的命令
|
||||
|
||||
```
|
||||
# shutdown -h
|
||||
Shutdown scheduled for Mon 2018-10-08 06:42:31 EDT, use 'shutdown -c' to cancel.
|
||||
|
||||
[email protected]#
|
||||
Broadcast message from [email protected] (Mon 2018-10-08 06:41:31 EDT):
|
||||
|
||||
The system is going down for power-off at Mon 2018-10-08 06:42:31 EDT!
|
||||
|
||||
```
|
||||
|
||||
其他的登录用户都能在中断中看到如下的广播消息:
|
||||
|
||||
```
|
||||
[[email protected] ~]$
|
||||
Broadcast message from [email protected] (Mon 2018-10-08 06:41:31 EDT):
|
||||
|
||||
The system is going down for power-off at Mon 2018-10-08 06:42:31 EDT!
|
||||
|
||||
```
|
||||
|
||||
对于使用了 Halt 选项.
|
||||
|
||||
```
|
||||
# shutdown -H
|
||||
Shutdown scheduled for Mon 2018-10-08 06:37:53 EDT, use 'shutdown -c' to cancel.
|
||||
|
||||
[email protected]#
|
||||
Broadcast message from [email protected] (Mon 2018-10-08 06:36:53 EDT):
|
||||
|
||||
The system is going down for system halt at Mon 2018-10-08 06:37:53 EDT!
|
||||
|
||||
```
|
||||
|
||||
对于使用了 Poweroff 选项.
|
||||
|
||||
```
|
||||
# shutdown -P
|
||||
Shutdown scheduled for Mon 2018-10-08 06:40:07 EDT, use 'shutdown -c' to cancel.
|
||||
|
||||
[email protected]#
|
||||
Broadcast message from [email protected] (Mon 2018-10-08 06:39:07 EDT):
|
||||
|
||||
The system is going down for power-off at Mon 2018-10-08 06:40:07 EDT!
|
||||
|
||||
```
|
||||
|
||||
可以在您的终端上敲击 `Shutdown -c` 选项取消操作.
|
||||
|
||||
```
|
||||
# shutdown -c
|
||||
|
||||
Broadcast message from [email protected] (Mon 2018-10-08 06:39:09 EDT):
|
||||
|
||||
The system shutdown has been cancelled at Mon 2018-10-08 06:40:09 EDT!
|
||||
|
||||
```
|
||||
|
||||
其他的登录用户都能在中断中看到如下的广播消息:
|
||||
|
||||
```
|
||||
[[email protected] ~]$
|
||||
Broadcast message from [email protected] (Mon 2018-10-08 06:41:35 EDT):
|
||||
|
||||
The system shutdown has been cancelled at Mon 2018-10-08 06:42:35 EDT!
|
||||
|
||||
```
|
||||
|
||||
添加 time 参数, 如果你想在 `N` 秒之后执行关闭或重启操作. 这里, 您可以为所有登录用户添加自定义广播消息. 例如, 我们将在五分钟后重启设备.
|
||||
|
||||
```
|
||||
# shutdown -r +5 "To activate the latest Kernel"
|
||||
Shutdown scheduled for Mon 2018-10-08 07:13:16 EDT, use 'shutdown -c' to cancel.
|
||||
|
||||
[[email protected] ~]#
|
||||
Broadcast message from [email protected] (Mon 2018-10-08 07:08:16 EDT):
|
||||
|
||||
To activate the latest Kernel
|
||||
The system is going down for reboot at Mon 2018-10-08 07:13:16 EDT!
|
||||
|
||||
```
|
||||
|
||||
运行下面的命令立即重启 Linux 设备. 它会立即杀死所有进程并且重新启动系统.
|
||||
|
||||
```
|
||||
# shutdown -r now
|
||||
|
||||
```
|
||||
|
||||
* **`-r, --reboot:`** 重启设备.
|
||||
|
||||
### 方案 - 2: 如何通过 reboot 命令关闭和重启 Linux 系统
|
||||
|
||||
reboot 命令用于关闭和重启本地或远程设备. Reboot 命令拥有两个实用的选项.
|
||||
|
||||
它能够优雅的关闭和重启设备(就好像在系统菜单中惦记重启选项一样简单).
|
||||
|
||||
执行不带任何参数的 `reboot` 命令来重启 Linux 设备
|
||||
|
||||
```
|
||||
# reboot
|
||||
|
||||
```
|
||||
|
||||
执行带 `-p` 参数的 `reboot` 命令来关闭 Linux 设备或切断电源
|
||||
|
||||
```
|
||||
# reboot -p
|
||||
|
||||
```
|
||||
|
||||
* **`-p, --poweroff:`** 调用 halt 或 poweroff 命令, 切断设备电源.
|
||||
|
||||
|
||||
执行带 `-f` 参数的 `reboot` 命令来强制重启 Linux 设备(这类似按压 CPU 上的电源键)
|
||||
|
||||
```
|
||||
# reboot -f
|
||||
|
||||
```
|
||||
|
||||
* **`-f, --force:`** 立刻强制中断, 切断电源或重启
|
||||
|
||||
### 方案 - 3: 如何通过 init 命令关闭和重启 Linux 系统
|
||||
|
||||
init(initialization 的简写) 是系统启动的第一个进程.
|
||||
|
||||
他将会检查 /etc/inittab 文件并决定 linux 运行级别. 同时, 授权用户在 Linux 设备上执行关机或重启 操作. 这里存在从 0 到 6 的七个运行等级.
|
||||
|
||||
**建议阅读 :**
|
||||
**(#)** [如何检查 Linux 上所有运行的服务][3]
|
||||
|
||||
执行一下 init 命令关闭系统.
|
||||
```
|
||||
# init 0
|
||||
|
||||
```
|
||||
|
||||
* **`0:`** 中断 – 关闭系统.
|
||||
|
||||
运行下面的 init 命令重启设备
|
||||
```
|
||||
# init 6
|
||||
|
||||
```
|
||||
|
||||
* **`6:`** 重启 – 重启设备.
|
||||
|
||||
### 方案 - 4: 如何通过 halt 命令关闭和重启 Linux 系统
|
||||
|
||||
halt 命令用来切断电源或关闭远程 Linux 设备或本地主机.
|
||||
中断所有进程并关闭 cpu
|
||||
```
|
||||
# halt
|
||||
|
||||
```
|
||||
|
||||
### 方案 - 5: 如何通过 poweroff 命令关闭和重启 Linux 系统
|
||||
|
||||
poweroff 命令用来切断电源或关闭远程 Linux 设备或本地主机. Poweroff 很像 halt, 但是它可以关闭设备自身的单元(等和其他 PC 上的任何事物). 它会为 PSU 发送 ACPI 指令, 切断电源.
|
||||
|
||||
```
|
||||
# poweroff
|
||||
|
||||
```
|
||||
|
||||
### 方案 - 6: 如何通过 systemctl 命令关闭和重启 Linux 系统
|
||||
|
||||
Systemd 是一款适用于所有主流 Linux 发型版的全新 init 系统和系统管理器, 而不是传统的 SysV init 系统.
|
||||
|
||||
systemd 兼容与 SysV 和 LSB 脚本. 它能够替代 sysvinit 系统. systemd 是内核启动的第一个进程, 并持有序号为 1 的进程 PID.
|
||||
|
||||
**建议阅读 :**
|
||||
**(#)** [chkservice – 一款终端下系统单元管理工具][4]
|
||||
|
||||
它是一切进程的父进程, Fedora 15 是第一个适配安装 systemd 的发行版.
|
||||
It’s a parent process for everything and Fedora 15 is the first distribution which was adapted systemd instead of upstart.
|
||||
|
||||
systemctl 是命令行下管理系统, 守护进程, 开启服务(如 start, restart, stop, enable, disable, reload & status)的主要工具.
|
||||
|
||||
systemd 使用 .service 文件而不是 bash 脚本(SysVinit 用户使用的). systemd 将所有守护进程归与自身的 Linux cgroups 用户组下, 您可以浏览 /cgroup/systemd 文件查看系统层次等级
|
||||
|
||||
```
|
||||
# systemctl halt
|
||||
# systemctl poweroff
|
||||
# systemctl reboot
|
||||
# systemctl suspend
|
||||
# systemctl hibernate
|
||||
|
||||
```
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.2daygeek.com/6-commands-to-shutdown-halt-poweroff-reboot-the-linux-system/
|
||||
|
||||
作者：[Prakash Subramanian][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[cyleft](https://github.com/cyleft)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://www.2daygeek.com/author/prakash/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://www.2daygeek.com/11-methods-to-find-check-system-server-uptime-in-linux/
|
||||
[2]: https://www.2daygeek.com/tuptime-a-tool-to-report-the-historical-and-statistical-running-time-of-linux-system/
|
||||
[3]: https://www.2daygeek.com/how-to-check-all-running-services-in-linux/
|
||||
[4]: https://www.2daygeek.com/chkservice-a-tool-for-managing-systemd-units-from-linux-terminal/
|
||||
590
translated/tech/20181016 Lab 4- Preemptive Multitasking.md
Normal file
590
translated/tech/20181016 Lab 4- Preemptive Multitasking.md
Normal file
@ -0,0 +1,590 @@
|
||||
实验 4：抢占式多任务处理
|
||||
======
|
||||
### 实验 4：抢占式多任务处理
|
||||
|
||||
#### 简介
|
||||
|
||||
在本实验中，你将在多个同时活动的用户模式中的环境之间实现抢占式多任务处理。
|
||||
|
||||
在 Part A 中，你将在 JOS 中添加对多处理器的支持，以实现循环调度。并且添加基本的环境管理方面的系统调用（创建和销毁环境的系统调用、以及分配/映射内存）。
|
||||
|
||||
在 Part B 中，你将要实现一个类 Unix 的 `fork()`，它将允许一个用户模式中的环境去创建一个它自已的副本。
|
||||
|
||||
最后，在 Part C 中，你将在 JOS 中添加对进程间通讯（IPC）的支持，以允许不同用户模式环境之间进行显式通讯和同步。你也将要去添加对硬件时钟中断和优先权的支持。
|
||||
|
||||
##### 预备知识
|
||||
|
||||
使用 git 去提交你的实验 3 的源代码，并获取课程仓库的最新版本，然后创建一个名为 `lab4` 的本地分支，它跟踪我们的名为 `origin/lab4` 的远程 `lab4` 分支：
|
||||
|
||||
```markdown
|
||||
athena% cd ~/6.828/lab
|
||||
athena% add git
|
||||
athena% git pull
|
||||
Already up-to-date.
|
||||
athena% git checkout -b lab4 origin/lab4
|
||||
Branch lab4 set up to track remote branch refs/remotes/origin/lab4.
|
||||
Switched to a new branch "lab4"
|
||||
athena% git merge lab3
|
||||
Merge made by recursive.
|
||||
...
|
||||
athena%
|
||||
```
|
||||
|
||||
实验 4 包含了一些新的源文件，在开始之前你应该去浏览一遍：
|
||||
```markdown
|
||||
kern/cpu.h Kernel-private definitions for multiprocessor support
|
||||
kern/mpconfig.c Code to read the multiprocessor configuration
|
||||
kern/lapic.c Kernel code driving the local APIC unit in each processor
|
||||
kern/mpentry.S Assembly-language entry code for non-boot CPUs
|
||||
kern/spinlock.h Kernel-private definitions for spin locks, including the big kernel lock
|
||||
kern/spinlock.c Kernel code implementing spin locks
|
||||
kern/sched.c Code skeleton of the scheduler that you are about to implement
|
||||
```
|
||||
|
||||
##### 实验要求
|
||||
|
||||
本实验分为三部分：Part A、Part B、和 Part C。我们计划为每个部分分配一周的时间。
|
||||
|
||||
和以前一样，你需要完成实验中出现的、所有常规练习和至少一个挑战问题。（不是每个部分做一个挑战问题，是整个实验做一个挑战问题即可。）另外，你还要写出你实现的挑战问题的详细描述。如果你实现了多个挑战问题，你只需写出其中一个即可，虽然我们的课程欢迎你完成越多的挑战越好。在动手实验之前，请将你的挑战问题的答案写在一个名为 `answers-lab4.txt` 的文件中，并把它放在你的 `lab` 目录的根下。
|
||||
|
||||
#### Part A：多处理器支持和协调多任务处理
|
||||
|
||||
在本实验的第一部分，将去扩展你的 JOS 内核，以便于它能够在一个多处理器的系统上运行，并且要在 JOS 内核中实现一些新的系统调用，以便于它允许用户级环境创建附加的新环境。你也要去实现协调的循环调度，在当前的环境自愿放弃 CPU（或退出）时，允许内核将一个环境切换到另一个环境。稍后在 Part C 中，你将要实现抢占调度，它允许内核在环境占有 CPU 一段时间后，从这个环境上重新取回对 CPU 的控制，那怕是在那个环境不配合的情况下。
|
||||
|
||||
##### 多处理器支持
|
||||
|
||||
我们继续去让 JOS 支持 “对称多处理器”（SMP），在一个多处理器的模型中，所有 CPU 们都有平等访问系统资源（如内存和 I/O 总线）的权利。虽然在 SMP 中所有 CPU 们都有相同的功能，但是在引导进程的过程中，它们被分成两种类型：引导程序处理器（BSP）负责初始化系统和引导操作系统；而在操作系统启动并正常运行后，应用程序处理器（AP）将被 BSP 激活。哪个处理器做 BSP 是由硬件和 BIOS 来决定的。到目前为止，你所有的已存在的 JOS 代码都是运行在 BSP 上的。
|
||||
|
||||
在一个 SMP 系统上，每个 CPU 都伴有一个本地 APIC（LAPIC）单元。这个 LAPIC 单元负责传递系统中的中断。LAPIC 还为它所连接的 CPU 提供一个唯一的标识符。在本实验中，我们将使用 LAPIC 单元（它在 `kern/lapic.c` 中）中的下列基本功能：
|
||||
|
||||
* 读取 LAPIC 标识符（APIC ID），去告诉那个 CPU 现在我们的代码正在它上面运行（查看 `cpunum()`）。
|
||||
* 从 BSP 到 AP 之间发送处理器间中断（IPI） `STARTUP`，以启动其它 CPU（查看 `lapic_startap()`）。
|
||||
* 在 Part C 中，我们设置 LAPIC 的内置定时器去触发时钟中断，以便于支持抢占式多任务处理（查看 `apic_init()`）。
|
||||
|
||||
|
||||
|
||||
一个处理器使用内存映射的 I/O（MMIO）来访问它的 LAPIC。在 MMIO 中，一部分物理内存是硬编码到一些 I/O 设备的寄存器中，因此，访问内存时一般可以使用相同的 `load/store` 指令去访问设备的寄存器。正如你所看到的，在物理地址 `0xA0000` 处就是一个 IO 入口（就是我们写入 VGA 缓冲区的入口）。LAPIC 就在那里，它从物理地址 `0xFE000000` 处（4GB 减去 32MB 处）开始，这个地址对于我们在 KERNBASE 处使用直接映射访问来说太高了。JOS 虚拟内存映射在 `MMIOBASE` 处，留下一个 4MB 的空隙，以便于我们有一个地方，能像这样去映射设备。由于在后面的实验中，我们将介绍更多的 MMIO 区域，你将要写一个简单的函数，从这个区域中去分配空间，并将设备的内存映射到那里。
|
||||
|
||||
```markdown
|
||||
练习 1、实现 `kern/pmap.c` 中的 `mmio_map_region`。去看一下它是如何使用的，从 `kern/lapic.c` 中的 `lapic_init` 开始看起。在 `mmio_map_region` 的测试运行之前，你还要做下一个练习。
|
||||
```
|
||||
|
||||
###### 引导应用程序处理器
|
||||
|
||||
在引导应用程序处理器之前，引导程序处理器应该会首先去收集关于多处理器系统的信息，比如总的 CPU 数、它们的 APIC ID 以及 LAPIC 单元的 MMIO 地址。在 `kern/mpconfig.c` 中的 `mp_init()` 函数，通过读取内存中位于 BIOS 区域里的 MP 配置表来获得这些信息。
|
||||
|
||||
`boot_aps()` 函数（在 `kern/init.c` 中）驱动 AP 的引导过程。AP 们在实模式中开始，与 `boot/boot.S` 中启动引导加载程序非常相似。因此，`boot_aps()` 将 AP 入口代码（`kern/mpentry.S`）复制到实模式中的那个可寻址内存地址上。不像使用引导加载程序那样，我们可以控制 AP 将从哪里开始运行代码；我们复制入口代码到 `0x7000`（`MPENTRY_PADDR`）处，但是复制到任何低于 640KB 的、未使用的、页对齐的物理地址上都是可以运行的。
|
||||
|
||||
在那之后，通过发送 IPI `STARTUP` 到相关 AP 的 LAPIC 单元，以及一个初始的 `CS:IP` 地址（AP 将从那儿开始运行它的入口代码，在我们的案例中是 `MPENTRY_PADDR` ），`boot_aps()` 将一个接一个地激活 AP。在 `kern/mpentry.S` 中的入口代码非常类似于 `boot/boot.S`。在一些简短的设置之后，它启用分页，使 AP 进入保护模式，然后调用 C 设置程序 `mp_main()`（它也在 `kern/init.c` 中）。在继续唤醒下一个 AP 之前， `boot_aps()` 将等待这个 AP 去传递一个 `CPU_STARTED` 标志到它的 `struct CpuInfo` 中的 `cpu_status` 字段中。
|
||||
|
||||
```markdown
|
||||
练习 2、阅读 `kern/init.c` 中的 `boot_aps()` 和 `mp_main()`，以及在 `kern/mpentry.S` 中的汇编代码。确保你理解了在 AP 引导过程中的控制流转移。然后修改在 `kern/pmap.c` 中的、你自己的 `page_init()`，实现避免在 `MPENTRY_PADDR` 处添加页到空闲列表上，以便于我们能够在物理地址上安全地复制和运行 AP 引导程序代码。你的代码应该会通过更新后的 `check_page_free_list()` 的测试（但可能会在更新后的 `check_kern_pgdir()` 上测试失败，我们在后面会修复它）。
|
||||
```
|
||||
|
||||
```markdown
|
||||
问题
|
||||
1、比较 `kern/mpentry.S` 和 `boot/boot.S`。记住，那个 `kern/mpentry.S` 是编译和链接后的，运行在 `KERNBASE` 上面的，就像内核中的其它程序一样，宏 `MPBOOTPHYS` 的作用是什么？为什么它需要在 `kern/mpentry.S` 中，而不是在 `boot/boot.S` 中？换句话说，如果在 `kern/mpentry.S` 中删掉它，会发生什么错误？
|
||||
提示：回顾链接地址和加载地址的区别，我们在实验 1 中讨论过它们。
|
||||
```
|
||||
|
||||
|
||||
###### 每个 CPU 的状态和初始化
|
||||
|
||||
当写一个多处理器操作系统时，区分每个 CPU 的状态是非常重要的，而每个 CPU 的状态对其它处理器是不公开的，而全局状态是整个系统共享的。`kern/cpu.h` 定义了大部分每个 CPU 的状态，包括 `struct CpuInfo`，它保存了每个 CPU 的变量。`cpunum()` 总是返回调用它的那个 CPU 的 ID，它可以被用作是数组的索引，比如 `cpus`。或者，宏 `thiscpu` 是当前 CPU 的 `struct CpuInfo` 缩略表示。
|
||||
|
||||
下面是你应该知道的每个 CPU 的状态：
|
||||
|
||||
* **每个 CPU 的内核栈**
|
||||
因为内核能够同时捕获多个 CPU，因此，我们需要为每个 CPU 准备一个单独的内核栈，以防止它们运行的程序之间产生相互干扰。数组 `percpu_kstacks[NCPU][KSTKSIZE]` 为 NCPU 的内核栈资产保留了空间。
|
||||
|
||||
在实验 2 中，你映射的 `bootstack` 所引用的物理内存，就作为 `KSTACKTOP` 以下的 BSP 的内核栈。同样，在本实验中，你将每个 CPU 的内核栈映射到这个区域，而使用保护页做为它们之间的缓冲区。CPU 0 的栈将从 `KSTACKTOP` 处向下增长；CPU 1 的栈将从 CPU 0 的栈底部的 `KSTKGAP` 字节处开始，依次类推。在 `inc/memlayout.h` 中展示了这个映射布局。
|
||||
|
||||
* **每个 CPU 的 TSS 和 TSS 描述符**
|
||||
为了指定每个 CPU 的内核栈在哪里，也需要有一个每个 CPU 的任务状态描述符（TSS）。CPU _i_ 的任务状态描述符是保存在 `cpus[i].cpu_ts` 中，而对应的 TSS 描述符是定义在 GDT 条目 `gdt[(GD_TSS0 >> 3) + i]` 中。在 `kern/trap.c` 中定义的全局变量 `ts` 将不再被使用。
|
||||
|
||||
* **每个 CPU 当前的环境指针**
|
||||
由于每个 CPU 都能同时运行不同的用户进程，所以我们重新定义了符号 `curenv`，让它指向到 `cpus[cpunum()].cpu_env`（或 `thiscpu->cpu_env`），它指向到当前 CPU（代码正在运行的那个 CPU）上当前正在运行的环境上。
|
||||
|
||||
* **每个 CPU 的系统寄存器**
|
||||
所有的寄存器，包括系统寄存器，都是一个 CPU 私有的。所以，初始化这些寄存器的指令，比如 `lcr3()`、`ltr()`、`lgdt()`、`lidt()`、等待，必须在每个 CPU 上运行一次。函数 `env_init_percpu()` 和 `trap_init_percpu()` 就是为此目的而定义的。
|
||||
|
||||
|
||||
|
||||
```markdown
|
||||
练习 3、修改 `mem_init_mp()`（在 `kern/pmap.c` 中）去映射每个 CPU 的栈从 `KSTACKTOP` 处开始，就像在 `inc/memlayout.h` 中展示的那样。每个栈的大小是 `KSTKSIZE` 字节加上未映射的保护页 `KSTKGAP` 的字节。你的代码应该会通过在 `check_kern_pgdir()` 中的新的检查。
|
||||
```
|
||||
|
||||
```markdown
|
||||
练习 4、在 `trap_init_percpu()`（在 `kern/trap.c` 文件中）的代码为 BSP 初始化 TSS 和 TSS 描述符。在实验 3 中它就运行过，但是当它运行在其它的 CPU 上就会出错。修改这些代码以便它能在所有 CPU 上都正常运行。（注意：你的新代码应该还不能使用全局变量 `ts`）
|
||||
```
|
||||
|
||||
在你完成上述练习后，在 QEMU 中使用 4 个 CPU（使用 `make qemu CPUS=4` 或 `make qemu-nox CPUS=4`）来运行 JOS，你应该看到类似下面的输出：
|
||||
|
||||
```c
|
||||
...
|
||||
Physical memory: 66556K available, base = 640K, extended = 65532K
|
||||
check_page_alloc() succeeded!
|
||||
check_page() succeeded!
|
||||
check_kern_pgdir() succeeded!
|
||||
check_page_installed_pgdir() succeeded!
|
||||
SMP: CPU 0 found 4 CPU(s)
|
||||
enabled interrupts: 1 2
|
||||
SMP: CPU 1 starting
|
||||
SMP: CPU 2 starting
|
||||
SMP: CPU 3 starting
|
||||
```
|
||||
|
||||
###### 锁定
|
||||
|
||||
在 `mp_main()` 中初始化 AP 后我们的代码快速运行起来。在你更进一步增强 AP 之前，我们需要首先去处理多个 CPU 同时运行内核代码的争用状况。达到这一目标的最简单的方法是使用大内核锁。大内核锁是一个单个的全局锁，当一个环境进入内核模式时，它将被加锁，而这个环境返回到用户模式时它将释放锁。在这种模型中，在用户模式中运行的环境可以同时运行在任何可用的 CPU 上，但是只有一个环境能够运行在内核模式中；而任何尝试进入内核模式的其它环境都被强制等待。
|
||||
|
||||
`kern/spinlock.h` 中声明大内核锁，即 `kernel_lock`。它也提供 `lock_kernel()` 和 `unlock_kernel()`，快捷地去获取/释放锁。你应该在以下的四个位置应用大内核锁：
|
||||
|
||||
* 在 `i386_init()` 时，在 BSP 唤醒其它 CPU 之前获取锁。
|
||||
* 在 `mp_main()` 时，在初始化 AP 之后获取锁，然后调用 `sched_yield()` 在这个 AP 上开始运行环境。
|
||||
* 在 `trap()` 时，当从用户模式中捕获一个<ruby>陷阱<rt>trap</rt></ruby>时获取锁。在检查 `tf_cs` 的低位比特，以确定一个陷阱是发生在用户模式还是内核模式时。
|
||||
* 在 `env_run()` 中，在切换到用户模式之前释放锁。不能太早也不能太晚，否则你将可能会产生争用或死锁。
|
||||
|
||||
|
||||
```markdown
|
||||
练习 5、在上面所描述的情况中，通过在合适的位置调用 `lock_kernel()` 和 `unlock_kernel()` 应用大内核锁。
|
||||
```
|
||||
|
||||
如果你的锁定是正确的，如何去测试它？实际上，到目前为止，还无法测试！但是在下一个练习中，你实现了调度之后，就可以测试了。
|
||||
|
||||
```
|
||||
问题
|
||||
2、看上去使用一个大内核锁，可以保证在一个时间中只有一个 CPU 能够运行内核代码。为什么每个 CPU 仍然需要单独的内核栈？描述一下使用一个共享内核栈出现错误的场景，即便是在它使用了大内核锁保护的情况下。
|
||||
```
|
||||
|
||||
```
|
||||
小挑战！大内核锁很简单，也易于使用。尽管如此，它消除了内核模式的所有并发。大多数现代操作系统使用不同的锁，一种称之为细粒度锁定的方法，去保护它们的共享的栈的不同部分。细粒度锁能够大幅提升性能，但是实现起来更困难并且易出错。如果你有足够的勇气，在 JOS 中删除大内核锁，去拥抱并发吧！
|
||||
|
||||
由你来决定锁的粒度（一个锁保护的数据量）。给你一个提示，你可以考虑在 JOS 内核中使用一个自旋锁去确保你独占访问这些共享的组件：
|
||||
|
||||
* 页分配器
|
||||
* 控制台驱动
|
||||
* 调度器
|
||||
* 你将在 Part C 中实现的进程间通讯（IPC）的状态
|
||||
```
|
||||
|
||||
|
||||
##### 循环调度
|
||||
|
||||
本实验中，你的下一个任务是去修改 JOS 内核，以使它能够在多个环境之间以“循环”的方式去交替。JOS 中的循环调度工作方式如下：
|
||||
|
||||
* 在新的 `kern/sched.c` 中的 `sched_yield()` 函数负责去选择一个新环境来运行。它按顺序以循环的方式在数组 `envs[]` 中进行搜索，在前一个运行的环境之后开始（或如果之前没有运行的环境，就从数组起点开始），选择状态为 `ENV_RUNNABLE` 的第一个环境（查看 `inc/env.h`），并调用 `env_run()` 去跳转到那个环境。
|
||||
* `sched_yield()` 必须做到，同一个时间在两个 CPU 上绝对不能运行相同的环境。它可以判断出一个环境正运行在一些 CPU（可能是当前 CPU）上，因为，那个正在运行的环境的状态将是 `ENV_RUNNING`。
|
||||
* 我们已经为你实现了一个新的系统调用 `sys_yield()`，用户环境调用它去调用内核的 `sched_yield()` 函数，并因此将自愿把对 CPU 的控制禅让给另外的一个环境。
|
||||
|
||||
|
||||
|
||||
```c
|
||||
练习 6、像上面描述的那样，在 `sched_yield()` 中实现循环调度。不要忘了去修改 `syscall()` 以派发 `sys_yield()`。
|
||||
|
||||
确保在 `mp_main` 中调用了 `sched_yield()`。
|
||||
|
||||
修改 `kern/init.c` 去创建三个（或更多个！）运行程序 `user/yield.c`的环境。
|
||||
|
||||
运行 `make qemu`。在它终止之前，你应该会看到像下面这样，在环境之间来回切换了五次。
|
||||
|
||||
也可以使用几个 CPU 来测试：make qemu CPUS=2。
|
||||
|
||||
...
|
||||
Hello, I am environment 00001000.
|
||||
Hello, I am environment 00001001.
|
||||
Hello, I am environment 00001002.
|
||||
Back in environment 00001000, iteration 0.
|
||||
Back in environment 00001001, iteration 0.
|
||||
Back in environment 00001002, iteration 0.
|
||||
Back in environment 00001000, iteration 1.
|
||||
Back in environment 00001001, iteration 1.
|
||||
Back in environment 00001002, iteration 1.
|
||||
...
|
||||
|
||||
在程序 `yield` 退出之后，系统中将没有可运行的环境，调度器应该会调用 JOS 内核监视器。如果它什么也没有发生，那么你应该在继续之前修复你的代码。
|
||||
```
|
||||
|
||||
```c
|
||||
问题
|
||||
3、在你实现的 `env_run()` 中，你应该会调用 `lcr3()`。在调用 `lcr3()` 的之前和之后，你的代码引用（至少它应该会）变量 `e`，它是 `env_run` 的参数。在加载 `%cr3` 寄存器时，MMU 使用的地址上下文将马上被改变。但一个虚拟地址（即 `e`）相对一个给定的地址上下文是有意义的 —— 地址上下文指定了物理地址到那个虚拟地址的映射。为什么指针 `e` 在地址切换之前和之后被解除引用？
|
||||
4、无论何时，内核从一个环境切换到另一个环境，它必须要确保旧环境的寄存器内容已经被保存，以便于它们稍后能够正确地还原。为什么？这种事件发生在什么地方？
|
||||
```
|
||||
|
||||
```c
|
||||
小挑战！给内核添加一个小小的调度策略，比如一个固定优先级的调度器，它将会给每个环境分配一个优先级，并且在执行中，较高优先级的环境总是比低优先级的环境优先被选定。如果你想去冒险一下，尝试实现一个类 Unix 的、优先级可调整的调度器，或者甚至是一个彩票调度器或跨步调度器。（可以在 Google 中查找“彩票调度”和“跨步调度”的相关资料）
|
||||
|
||||
写一个或两个测试程序，去测试你的调度算法是否工作正常（即，正确的算法能够按正确的次序运行）。如果你实现了本实验的 Part B 和 Part C 部分的 `fork()` 和 IPC，写这些测试程序可能会更容易。
|
||||
```
|
||||
|
||||
```markdown
|
||||
小挑战！目前的 JOS 内核还不能应用到使用了 x87 协处理器、MMX 指令集、或流式 SIMD 扩展（SSE）的 x86 处理器上。扩展数据结构 `Env` 去提供一个能够保存处理器的浮点状态的地方，并且扩展上下文切换代码，当从一个环境切换到另一个环境时，能够保存和还原正确的状态。`FXSAVE` 和 `FXRSTOR` 指令或许对你有帮助，但是需要注意的是，这些指令在旧的 x86 用户手册上没有，因为它是在较新的处理器上引入的。写一个用户级的测试程序，让它使用浮点做一些很酷的事情。
|
||||
```
|
||||
|
||||
##### 创建环境的系统调用
|
||||
|
||||
虽然你的内核现在已经有了在多个用户级环境之间切换的功能，但是由于内核初始化设置的原因，它在运行环境时仍然是受限的。现在，你需要去实现必需的 JOS 系统调用，以允许用户环境去创建和启动其它的新用户环境。
|
||||
|
||||
Unix 提供了 `fork()` 系统调用作为它的进程创建原语。Unix 的 `fork()` 通过复制调用进程（父进程）的整个地址空间去创建一个新进程（子进程）。从用户空间中能够观察到它们之间的仅有的两个差别是，它们的进程 ID 和父进程 ID（由 `getpid` 和 `getppid` 返回）。在父进程中，`fork()` 返回子进程 ID，而在子进程中，`fork()` 返回 0。默认情况下，每个进程得到它自己的私有地址空间，一个进程对内存的修改对另一个进程都是不可见的。
|
||||
|
||||
为创建一个用户模式下的新的环境，你将要提供一个不同的、更原始的 JOS 系统调用集。使用这些系统调用，除了其它类型的环境创建之外，你可以在用户空间中实现一个完整的类 Unix 的 `fork()`。你将要为 JOS 编写的新的系统调用如下：
|
||||
|
||||
* `sys_exofork`：
|
||||
这个系统调用创建一个新的空白的环境：在它的地址空间的用户部分什么都没有映射，并且它也不能运行。这个新的环境与 `sys_exofork` 调用时创建它的父环境的寄存器状态完全相同。在父进程中，`sys_exofork` 将返回新创建进程的 `envid_t`（如果环境分配失败的话，返回的是一个负的错误代码）。在子进程中，它将返回 0。（因为子进程从一开始就被标记为不可运行，在子进程中，`sys_exofork` 将并不真的返回，直到它的父进程使用 .... 显式地将子进程标记为可运行之前。）
|
||||
* `sys_env_set_status`：
|
||||
设置指定的环境状态为 `ENV_RUNNABLE` 或 `ENV_NOT_RUNNABLE`。这个系统调用一般是在，一个新环境的地址空间和寄存器状态已经完全初始化完成之后，用于去标记一个准备去运行的新环境。
|
||||
* `sys_page_alloc`：
|
||||
分配一个物理内存页，并映射它到一个给定的环境地址空间中、给定的一个虚拟地址上。
|
||||
* `sys_page_map`：
|
||||
从一个环境的地址空间中复制一个页映射（不是页内容！）到另一个环境的地址空间中，保持一个内存共享，以便于新的和旧的映射共同指向到同一个物理内存页。
|
||||
* `sys_page_unmap`：
|
||||
在一个给定的环境中，取消映射一个给定的已映射的虚拟地址。
|
||||
|
||||
|
||||
|
||||
上面所有的系统调用都接受环境 ID 作为参数，JOS 内核支持一个约定，那就是用值 “0” 来表示“当前环境”。这个约定在 `kern/env.c` 中的 `envid2env()` 中实现的。
|
||||
|
||||
在我们的 `user/dumbfork.c` 中的测试程序里，提供了一个类 Unix 的 `fork()` 的非常原始的实现。这个测试程序使用了上面的系统调用，去创建和运行一个复制了它自己地址空间的子环境。然后，这两个环境像前面的练习那样使用 `sys_yield` 来回切换，父进程在迭代 10 次后退出，而子进程在迭代 20 次后退出。
|
||||
|
||||
```c
|
||||
练习 7、在 `kern/syscall.c` 中实现上面描述的系统调用，并确保 `syscall()` 能调用它们。你将需要使用 `kern/pmap.c` 和 `kern/env.c` 中的多个函数，尤其是要用到 `envid2env()`。目前，每当你调用 `envid2env()` 时，在 `checkperm` 中传递参数 1。你务必要做检查任何无效的系统调用参数，在那个案例中，就返回了 `-E_INVAL`。使用 `user/dumbfork` 测试你的 JOS 内核，并在继续之前确保它运行正常。
|
||||
```
|
||||
|
||||
```c
|
||||
小挑战！添加另外的系统调用，必须能够读取已存在的、所有的、环境的重要状态，以及设置它们。然后实现一个能够 fork 出子环境的用户模式程序，运行它一小会（即，迭代几次 `sys_yield()`），然后取得几张屏幕截图或子环境的检查点，然后运行子环境一段时间，然后还原子环境到检查点时的状态，然后从这里继续开始。这样，你就可以有效地从一个中间状态“回放”了子环境的运行。确保子环境与用户使用 `sys_cgetc()` 或 `readline()` 执行了一些交互，这样，那个用户就能够查看和突变它的内部状态，并且你可以通过给子环境给定一个选择性遗忘的状况，来验证你的检查点/重启动的有效性，使它“遗忘”了在某些点之前发生的事情。
|
||||
```
|
||||
|
||||
到此为止，已经完成了本实验的 Part A 部分；在你运行 `make grade` 之前确保它通过了所有的 Part A 的测试，并且和以往一样，使用 `make handin` 去提交它。如果你想尝试找出为什么一些特定的测试是失败的，可以运行 `run ./grade-lab4 -v`，它将向你展示内核构建的输出，和测试失败时的 QEMU 运行情况。当测试失败时，这个脚本将停止运行，然后你可以去检查 `jos.out` 的内容，去查看内核真实的输出内容。
|
||||
|
||||
#### Part B：写时复制 Fork
|
||||
|
||||
正如在前面提到过的，Unix 提供 `fork()` 系统调用作为它主要的进程创建原语。`fork()` 系统调用通过复制调用进程（父进程）的地址空间来创建一个新进程（子进程）。
|
||||
|
||||
xv6 Unix 的 `fork()` 从父进程的页上复制所有数据，然后将它分配到子进程的新页上。从本质上看，它与 `dumbfork()` 所采取的方法是相同的。复制父进程的地址空间到子进程，是 `fork()` 操作中代价最高的部分。
|
||||
|
||||
但是，一个对 `fork()` 的调用后，经常是紧接着几乎立即在子进程中有一个到 `exec()` 的调用，它使用一个新程序来替换子进程的内存。这是 shell 默认去做的事，在这种情况下，在复制父进程地址空间上花费的时间是非常浪费的，因为在调用 `exec()` 之前，子进程使用的内存非常少。
|
||||
|
||||
基于这个原因，Unix 的最新版本利用了虚拟内存硬件的优势，允许父进程和子进程去共享映射到它们各自地址空间上的内存，直到其中一个进程真实地修改了它们为止。这个技术就是众所周知的“写时复制”。为实现这一点，在 `fork()` 时，内核将复制从父进程到子进程的地址空间的映射，而不是所映射的页的内容，并且同时设置正在共享中的页为只读。当两个进程中的其中一个尝试去写入到它们共享的页上时，进程将产生一个页故障。在这时，Unix 内核才意识到那个页实际上是“虚拟的”或“写时复制”的副本，然后它生成一个新的、私有的、那个发生页故障的进程可写的、页的副本。在这种方式中，个人的页的内容并不进行真实地复制，直到它们真正进行写入时才进行复制。这种优化使得一个`fork()` 后在子进程中跟随一个 `exec()` 变得代价很低了：子进程在调用 `exec()` 时或许仅需要复制一个页（它的栈的当前页）。
|
||||
|
||||
在本实验的下一段中，你将实现一个带有“写时复制”的“真正的”类 Unix 的 `fork()`，来作为一个常规的用户空间库。在用户空间中实现 `fork()` 和写时复制有一个好处就是，让内核始终保持简单，并且因此更不易出错。它也让个别的用户模式程序在 `fork()` 上定义了它们自己的语义。一个有略微不同实现的程序（例如，代价昂贵的、总是复制的 `dumbfork()` 版本，或父子进程真实共享内存的后面的那一个），它自己可以很容易提供。
|
||||
|
||||
##### 用户级页故障处理
|
||||
|
||||
一个用户级写时复制 `fork()` 需要知道关于在写保护页上的页故障相关的信息，因此，这是你首先需要去实现的东西。对用户级页故障处理来说，写时复制仅是众多可能的用途之一。
|
||||
|
||||
它通常是配置一个地址空间，因此在一些动作需要时，那个页故障将指示去处。例如，主流的 Unix 内核在一个新进程的栈区域中，初始的映射仅是单个页，并且在后面“按需”分配和映射额外的栈页，因此，进程的栈消费是逐渐增加的，并因此导致在尚未映射的栈地址上发生页故障。在每个进程空间的区域上发生一个页故障时，一个典型的 Unix 内核必须对它的动作保持跟踪。例如，在栈区域中的一个页故障，一般情况下将分配和映射新的物理内存页。一个在程序的 BSS 区域中的页故障，一般情况下将分配一个新页，然后用 0 填充它并映射它。在一个按需分页的系统上的一个可执行文件中，在文本区域中的页故障将从磁盘上读取相应的二进制页并映射它。
|
||||
|
||||
内核跟踪有大量的信息，与传统的 Unix 方法不同，你将决定在每个用户空间中关于每个页故障应该做的事。用户空间中的 bug 危害都较小。这种设计带来了额外的好处，那就是允许程序员在定义它们的内存区域时，会有很好的灵活性；对于映射和访问基于磁盘文件系统上的文件时，你应该使用后面的用户级页故障处理。
|
||||
|
||||
###### 设置页故障服务程序
|
||||
|
||||
为了处理它自己的页故障，一个用户环境将需要在 JOS 内核上注册一个页故障服务程序入口。用户环境通过新的 `sys_env_set_pgfault_upcall` 系统调用来注册它的页故障入口。我们给结构 `Env` 增加了一个新的成员 `env_pgfault_upcall`，让它去记录这个信息。
|
||||
|
||||
```markdown
|
||||
练习 8、实现 `sys_env_set_pgfault_upcall` 系统调用。当查找目标环境的环境 ID 时，一定要确认启用了权限检查，因为这是一个“危险的”系统调用。
|
||||
```
|
||||
|
||||
###### 在用户环境中的正常和异常栈
|
||||
|
||||
在正常运行期间，JOS 中的一个用户环境运行在正常的用户栈上：它的 `ESP` 寄存器开始指向到 `USTACKTOP`，而它所推送的栈数据将驻留在 `USTACKTOP-PGSIZE` 和 `USTACKTOP-1`（含）之间的页上。但是，当在用户模式中发生页故障时，内核将在一个不同的栈上重新启动用户环境，运行一个用户级页故障指定的服务程序，即用户异常栈。其它，我们将让 JOS 内核为用户环境实现自动的“栈切换”，当从用户模式转换到内核模式时，x86 处理器就以大致相同的方式为 JOS 实现了栈切换。
|
||||
|
||||
JOS 用户异常栈也是一个页的大小，并且它的顶部被定义在虚拟地址 `UXSTACKTOP` 处，因此用户异常栈的有效字节数是从 `UXSTACKTOP-PGSIZE` 到 `UXSTACKTOP-1`（含）。尽管运行在异常栈上，用户页故障服务程序能够使用 JOS 的普通系统调用去映射新页或调整映射，以便于去修复最初导致页故障发生的各种问题。然后用户级页故障服务程序通过汇编语言 `stub` 返回到原始栈上的故障代码。
|
||||
|
||||
每个想去支持用户级页故障处理的用户环境，都需要为它自己的异常栈使用在 Part A 中介绍的 `sys_page_alloc()` 系统调用去分配内存。
|
||||
|
||||
###### 调用用户页故障服务程序
|
||||
|
||||
现在，你需要去修改 `kern/trap.c` 中的页故障处理代码，以能够处理接下来在用户模式中发生的页故障。我们将故障发生时用户环境的状态称之为捕获时状态。
|
||||
|
||||
如果这里没有注册页故障服务程序，JOS 内核将像前面那样，使用一个消息来销毁用户环境。否则，内核将在异常栈上设置一个陷阱帧，它看起来就像是来自 `inc/trap.h` 文件中的一个 `struct UTrapframe` 一样：
|
||||
|
||||
```assembly
|
||||
<-- UXSTACKTOP
|
||||
trap-time esp
|
||||
trap-time eflags
|
||||
trap-time eip
|
||||
trap-time eax start of struct PushRegs
|
||||
trap-time ecx
|
||||
trap-time edx
|
||||
trap-time ebx
|
||||
trap-time esp
|
||||
trap-time ebp
|
||||
trap-time esi
|
||||
trap-time edi end of struct PushRegs
|
||||
tf_err (error code)
|
||||
fault_va <-- %esp when handler is run
|
||||
|
||||
```
|
||||
|
||||
然后，内核安排这个用户环境重新运行，使用这个栈帧在异常栈上运行页故障服务程序；你必须搞清楚为什么发生这种情况。`fault_va` 是引发页故障的虚拟地址。
|
||||
|
||||
如果在一个异常发生时，用户环境已经在用户异常栈上运行，那么页故障服务程序自身将会失败。在这种情况下，你应该在当前的 `tf->tf_esp` 下，而不是在 `UXSTACKTOP` 下启动一个新的栈帧。
|
||||
|
||||
去测试 `tf->tf_esp` 是否已经在用户异常栈上准备好，可以去检查它是否在 `UXSTACKTOP-PGSIZE` 和 `UXSTACKTOP-1`（含）的范围内。
|
||||
|
||||
```markdown
|
||||
练习 9、实现在 `kern/trap.c` 中的 `page_fault_handler` 的代码，要求派发页故障到用户模式故障服务程序上。在写入到异常栈时，一定要采取适当的预防措施。（如果用户环境运行时溢出了异常栈，会发生什么事情？）
|
||||
```
|
||||
|
||||
###### 用户模式页故障入口点
|
||||
|
||||
接下来，你需要去实现汇编程序，它将调用 C 页故障服务程序，并在原始的故障指令处恢复程序运行。这个汇编程序是一个故障服务程序，它由内核使用 `sys_env_set_pgfault_upcall()` 来注册。
|
||||
|
||||
```markdown
|
||||
练习 10、实现在 `lib/pfentry.S` 中的 `_pgfault_upcall` 程序。最有趣的部分是返回到用户代码中产生页故障的原始位置。你将要直接返回到那里，不能通过内核返回。最难的部分是同时切换栈和重新加载 EIP。
|
||||
```
|
||||
|
||||
最后，你需要去实现用户级页故障处理机制的 C 用户库。
|
||||
|
||||
```c
|
||||
练习 11、完成 `lib/pgfault.c` 中的 `set_pgfault_handler()`。
|
||||
```
|
||||
|
||||
###### 测试
|
||||
|
||||
运行 `user/faultread`（make run-faultread）你应该会看到：
|
||||
|
||||
```c
|
||||
...
|
||||
[00000000] new env 00001000
|
||||
[00001000] user fault va 00000000 ip 0080003a
|
||||
TRAP frame ...
|
||||
[00001000] free env 00001000
|
||||
```
|
||||
|
||||
运行 `user/faultdie` 你应该会看到：
|
||||
|
||||
```c
|
||||
...
|
||||
[00000000] new env 00001000
|
||||
i faulted at va deadbeef, err 6
|
||||
[00001000] exiting gracefully
|
||||
[00001000] free env 00001000
|
||||
```
|
||||
|
||||
运行 `user/faultalloc` 你应该会看到：
|
||||
|
||||
```c
|
||||
...
|
||||
[00000000] new env 00001000
|
||||
fault deadbeef
|
||||
this string was faulted in at deadbeef
|
||||
fault cafebffe
|
||||
fault cafec000
|
||||
this string was faulted in at cafebffe
|
||||
[00001000] exiting gracefully
|
||||
[00001000] free env 00001000
|
||||
```
|
||||
|
||||
如果你只看到第一个 "this string” 行，意味着你没有正确地处理递归页故障。
|
||||
|
||||
运行 `user/faultallocbad` 你应该会看到：
|
||||
|
||||
```c
|
||||
...
|
||||
[00000000] new env 00001000
|
||||
[00001000] user_mem_check assertion failure for va deadbeef
|
||||
[00001000] free env 00001000
|
||||
```
|
||||
|
||||
确保你理解了为什么 `user/faultalloc` 和 `user/faultallocbad` 的行为是不一样的。
|
||||
|
||||
```markdown
|
||||
小挑战！扩展你的内核，让它不仅是页故障，而是在用户空间中运行的代码能够产生的所有类型的处理器异常，都能够被重定向到一个用户模式中的异常服务程序上。写出用户模式测试程序，去测试各种各样的用户模式异常处理，比如除零错误、一般保护故障、以及非法操作码。
|
||||
```
|
||||
|
||||
##### 实现写时复制 Fork
|
||||
|
||||
现在，你有个内核功能要去实现，那就是在用户空间中完整地实现写时复制 `fork()`。
|
||||
|
||||
我们在 `lib/fork.c` 中为你的 `fork()` 提供了一个框架。像 `dumbfork()`、`fork()` 应该会创建一个新环境，然后通过扫描父环境的整个地址空间，并在子环境中设置相关的页映射。重要的差别在于，`dumbfork()` 复制了页，而 `fork()` 开始只是复制了页映射。`fork()` 仅当在其中一个环境尝试去写入它时才复制每个页。
|
||||
|
||||
`fork()` 的基本控制流如下：
|
||||
|
||||
1. 父环境使用你在上面实现的 `set_pgfault_handler()` 函数，安装 `pgfault()` 作为 C 级页故障服务程序。
|
||||
|
||||
2. 父环境调用 `sys_exofork()` 去创建一个子环境。
|
||||
|
||||
3. 在它的地址空间中，低于 UTOP 位置的、每个可写入页、或写时复制页上，父环境调用 `duppage` 后，它应该会映射页写时复制到子环境的地址空间中，然后在它自己的地址空间中重新映射页写时复制。[ 注意：这里的顺序很重要（即，在父环境中标记之前，先在子环境中标记该页为 COW）！你能明白是为什么吗？尝试去想一个具体的案例，将顺序颠倒一下会发生什么样的问题。] `duppage` 把两个 PTE 都设置了，致使那个页不可写入，并且在 "avail” 字段中通过包含 `PTE_COW` 来从真正的只读页中区分写时复制页。
|
||||
|
||||
然而异常栈是不能通过这种方式重映射的。对于异常栈，你需要在子环境中分配一个新页。因为页故障服务程序不能做真实的复制，并且页故障服务程序是运行在异常栈上的，异常栈不能进行写时复制：那么谁来复制它呢？
|
||||
|
||||
`fork()` 也需要去处理存在的页，但不能写入或写时复制。
|
||||
|
||||
4. 父环境为子环境设置了用户页故障入口点，让它看起来像它自己的一样。
|
||||
|
||||
5. 现在，子环境准备去运行，所以父环境标记它为可运行。
|
||||
|
||||
|
||||
|
||||
|
||||
每次其中一个环境写一个还没有写入的写时复制页时，它将产生一个页故障。下面是用户页故障服务程序的控制流：
|
||||
|
||||
1. 内核传递页故障到 `_pgfault_upcall`，它调用 `fork()` 的 `pgfault()` 服务程序。
|
||||
2. `pgfault()` 检测到那个故障是一个写入（在错误代码中检查 `FEC_WR`），然后将那个页的 PTE 标记为 `PTE_COW`。如果不是一个写入，则崩溃。
|
||||
3. `pgfault()` 在一个临时位置分配一个映射的新页，并将故障页的内容复制进去。然后，故障服务程序以读取/写入权限映射新页到合适的地址，替换旧的只读映射。
|
||||
|
||||
|
||||
|
||||
对于上面的几个操作，用户级 `lib/fork.c` 代码必须查询环境的页表（即，那个页的 PTE 是否标记为 `PET_COW`）。为此，内核在 `UVPT` 位置精确地映射环境的页表。它使用一个 [聪明的映射技巧][1] 去标记它，以使用户代码查找 PTE 时更容易。`lib/entry.S` 设置 `uvpt` 和 `uvpd`，以便于你能够在 `lib/fork.c` 中轻松查找页表信息。
|
||||
|
||||
```c
|
||||
练习 12、在 `lib/fork.c` 中实现 `fork`、`duppage` 和 `pgfault`。
|
||||
|
||||
使用 `forktree` 程序测试你的代码。它应该会产生下列的信息，在信息中会有 'new env'、'free env'、和 'exiting gracefully' 这样的字眼。信息可能不是按如下的顺序出现的，并且环境 ID 也可能不一样。
|
||||
|
||||
1000: I am ''
|
||||
1001: I am '0'
|
||||
2000: I am '00'
|
||||
2001: I am '000'
|
||||
1002: I am '1'
|
||||
3000: I am '11'
|
||||
3001: I am '10'
|
||||
4000: I am '100'
|
||||
1003: I am '01'
|
||||
5000: I am '010'
|
||||
4001: I am '011'
|
||||
2002: I am '110'
|
||||
1004: I am '001'
|
||||
1005: I am '111'
|
||||
1006: I am '101'
|
||||
```
|
||||
|
||||
```c
|
||||
小挑战！实现一个名为 `sfork()` 的共享内存的 `fork()`。这个版本的 `sfork()` 中，父子环境共享所有的内存页（因此，一个环境中对内存写入，就会改变另一个环境数据），除了在栈区域中的页以外，它应该使用写时复制来处理这些页。修改 `user/forktree.c` 去使用 `sfork()` 而是不常见的 `fork()`。另外，你在 Part C 中实现了 IPC 之后，使用你的 `sfork()` 去运行 `user/pingpongs`。你将找到提供全局指针 `thisenv` 功能的一个新方式。
|
||||
```
|
||||
|
||||
```markdown
|
||||
小挑战！你实现的 `fork` 将产生大量的系统调用。在 x86 上，使用中断切换到内核模式将产生较高的代价。增加系统调用接口，以便于它能够一次发送批量的系统调用。然后修改 `fork` 去使用这个接口。
|
||||
|
||||
你的新的 `fork` 有多快？
|
||||
|
||||
你可以用一个分析来论证，批量提交对你的 `fork` 的性能改变，以它来（粗略地）回答这个问题：使用一个 `int 0x30` 指令的代价有多高？在你的 `fork` 中运行了多少次 `int 0x30` 指令？访问 `TSS` 栈切换的代价高吗？等待 ...
|
||||
|
||||
或者，你可以在真实的硬件上引导你的内核，并且真实地对你的代码做基准测试。查看 `RDTSC`（读取时间戳计数器）指令，它的定义在 IA32 手册中，它计数自上一次处理器重置以来流逝的时钟周期数。QEMU 并不能真实地模拟这个指令（它能够计数运行的虚拟指令数量，或使用主机的 TSC，但是这两种方式都不能反映真实的 CPU 周期数）。
|
||||
```
|
||||
|
||||
到此为止，Part B 部分结束了。在你运行 `make grade` 之前，确保你通过了所有的 Part B 部分的测试。和以前一样，你可以使用 `make handin` 去提交你的实验。
|
||||
|
||||
#### Part C：抢占式多任务处理和进程间通讯（IPC）
|
||||
|
||||
在实验 4 的最后部分，你将修改内核去抢占不配合的环境，并允许环境之间显式地传递消息。
|
||||
|
||||
##### 时钟中断和抢占
|
||||
|
||||
运行测试程序 `user/spin`。这个测试程序 fork 出一个子环境，它控制了 CPU 之后，就永不停歇地运转起来。无论是父环境还是内核都不能回收对 CPU 的控制。从用户模式环境中保护系统免受 bug 或恶意代码攻击的角度来看，这显然不是个理想的状态，因为任何用户模式环境都能够通过简单的无限循环，并永不归还 CPU 控制权的方式，让整个系统处于暂停状态。为了允许内核去抢占一个运行中的环境，从其中夺回对 CPU 的控制权，我们必须去扩展 JOS 内核，以支持来自硬件时钟的外部硬件中断。
|
||||
|
||||
###### 中断规则
|
||||
|
||||
外部中断（即：设备中断）被称为 IRQ。现在有 16 个可能出现的 IRQ，编号 0 到 15。从 IRQ 号到 IDT 条目的映射是不固定的。在 `picirq.c` 中的 `pic_init` 映射 IRQ 0 - 15 到 IDT 条目 `IRQ_OFFSET` 到 `IRQ_OFFSET+15`。
|
||||
|
||||
在 `inc/trap.h` 中，`IRQ_OFFSET` 被定义为十进制的 32。所以，IDT 条目 32 - 47 对应 IRQ 0 - 15。例如，时钟中断是 IRQ 0，所以 IDT[IRQ_OFFSET+0]（即：IDT[32]）包含了内核中时钟中断服务程序的地址。这里选择 `IRQ_OFFSET` 是为了处理器异常不会覆盖设备中断，因为它会引起显而易见的混淆。（事实上，在早期运行 MS-DOS 的 PC 上， `IRQ_OFFSET` 事实上是 0，它确实导致了硬件中断服务程序和处理器异常处理之间的混淆！）
|
||||
|
||||
在 JOS 中，相比 xv6 Unix 我们做了一个重要的简化。当处于内核模式时，外部设备中断总是被关闭（并且，像 xv6 一样，当处于用户空间时，再打开外部设备的中断）。外部中断由 `%eflags` 寄存器的 `FL_IF` 标志位来控制（查看 `inc/mmu.h`）。当这个标志位被设置时，外部中断被打开。虽然这个标志位可以使用几种方式来修改，但是为了简化，我们只通过进程所保存和恢复的 `%eflags` 寄存器值，作为我们进入和离开用户模式的方法。
|
||||
|
||||
处于用户环境中时，你将要确保 `FL_IF` 标志被设置，以便于出现一个中断时，它能够通过处理器来传递，让你的中断代码来处理。否则，中断将被屏蔽或忽略，直到中断被重新打开后。我们使用引导加载程序的第一个指令去屏蔽中断，并且到目前为止，还没有去重新打开它们。
|
||||
|
||||
```markdown
|
||||
练习 13、修改 `kern/trapentry.S` 和 `kern/trap.c` 去初始化 IDT 中的相关条目，并为 IRQ 0 到 15 提供服务程序。然后修改 `kern/env.c` 中的 `env_alloc()` 的代码，以确保在用户环境中，中断总是打开的。
|
||||
|
||||
另外，在 `sched_halt()` 中取消注释 `sti` 指令，以便于空闲的 CPU 取消屏蔽中断。
|
||||
|
||||
当调用一个硬件中断服务程序时，处理器不会推送一个错误代码。在这个时候，你可能需要重新阅读 [80386 参考手册][2] 的 9.2 节，或 [IA-32 Intel 架构软件开发者手册 卷 3][3] 的 5.8 节。
|
||||
|
||||
在完成这个练习后，如果你在你的内核上使用任意的测试程序去持续运行（即：`spin`），你应该会看到内核输出中捕获的硬件中断的捕获帧。虽然在处理器上已经打开了中断，但是 JOS 并不能处理它们，因此，你应该会看到在当前运行的用户环境中每个中断的错误属性并被销毁，最终环境会被销毁并进入到监视器中。
|
||||
```
|
||||
|
||||
###### 处理时钟中断
|
||||
|
||||
在 `user/spin` 程序中，子环境首先运行之后，它只是进入一个高速循环中，并且内核再无法取得 CPU 控制权。我们需要对硬件编程，定期产生时钟中断，它将强制将 CPU 控制权返还给内核，在内核中，我们就能够将控制权切换到另外的用户环境中。
|
||||
|
||||
我们已经为你写好了对 `lapic_init` 和 `pic_init`（来自 `init.c` 中的 `i386_init`）的调用，它将设置时钟和中断控制器去产生中断。现在，你需要去写代码来处理这些中断。
|
||||
|
||||
```markdown
|
||||
练习 14、修改内核的 `trap_dispatch()` 函数，以便于在时钟中断发生时，它能够调用 `sched_yield()` 去查找和运行一个另外的环境。
|
||||
|
||||
现在，你应该能够用 `user/spin` 去做测试了：父环境应该会 fork 出子环境，`sys_yield()` 到它许多次，但每次切换之后，将重新获得对 CPU 的控制权，最后杀死子环境后优雅地终止。
|
||||
```
|
||||
|
||||
这是做回归测试的好机会。确保你没有弄坏本实验的前面部分，确保打开中断能够正常工作（即： `forktree`）。另外，尝试使用 ` make CPUS=2 target` 在多个 CPU 上运行它。现在，你应该能够通过 `stresssched` 测试。可以运行 `make grade` 去确认。现在，你的得分应该是 65 分了（总分为 80）。
|
||||
|
||||
##### 进程间通讯（IPC）
|
||||
|
||||
（严格来说，在 JOS 中这是“环境间通讯” 或 “IEC”，但所有人都称它为 IPC，因此我们使用标准的术语。）
|
||||
|
||||
我们一直专注于操作系统的隔离部分，这就产生了一种错觉，好像每个程序都有一个机器完整地为它服务。一个操作系统的另一个重要服务是，当它们需要时，允许程序之间相互通讯。让程序与其它程序交互可以让它的功能更加强大。Unix 的管道模型就是一个权威的示例。
|
||||
|
||||
进程间通讯有许多模型。关于哪个模型最好的争论从来没有停止过。我们不去参与这种争论。相反，我们将要实现一个简单的 IPC 机制，然后尝试使用它。
|
||||
|
||||
###### JOS 中的 IPC
|
||||
|
||||
你将要去实现另外几个 JOS 内核的系统调用，由它们共同来提供一个简单的进程间通讯机制。你将要实现两个系统调用，`sys_ipc_recv` 和 `sys_ipc_try_send`。然后你将要实现两个库去封装 `ipc_recv` 和 `ipc_send`。
|
||||
|
||||
用户环境可以使用 JOS 的 IPC 机制相互之间发送 “消息” 到每个其它环境，这些消息有两部分组成：一个单个的 32 位值，和可选的一个单个页映射。允许环境在消息中传递页映射，提供了一个高效的方式，传输比一个仅适合单个的 32 位整数更多的数据，并且也允许环境去轻松地设置安排共享内存。
|
||||
|
||||
###### 发送和接收消息
|
||||
|
||||
一个环境通过调用 `sys_ipc_recv` 去接收消息。这个系统调用将取消对当前环境的调度，并且不会再次去运行它，直到消息被接收为止。当一个环境正在等待接收一个消息时，任何其它环境都能够给它发送一个消息 — 而不仅是一个特定的环境，而且不仅是与接收环境有父子关系的环境。换句话说，你在 Part A 中实现的权限检查将不会应用到 IPC 上，因为 IPC 系统调用是经过慎重设计的，因此可以认为它是“安全的”：一个环境并不能通过给它发送消息导致另一个环境发生故障（除非目标环境也存在 Bug）。
|
||||
|
||||
尝试去发送一个值时，一个环境使用接收者的 ID 和要发送的值去调用 `sys_ipc_try_send` 来发送。如果指定的环境正在接收（它调用了 `sys_ipc_recv`，但尚未收到值），那么这个环境将去发送消息并返回 0。否则将返回 `-E_IPC_NOT_RECV` 来表示目标环境当前不希望来接收值。
|
||||
|
||||
在用户空间中的一个库函数 `ipc_recv` 将去调用 `sys_ipc_recv`，然后，在当前环境的 `struct Env` 中查找关于接收到的值的相关信息。
|
||||
|
||||
同样，一个库函数 `ipc_send` 将去不停地调用 `sys_ipc_try_send` 来发送消息，直到发送成功为止。
|
||||
|
||||
###### 转移页
|
||||
|
||||
当一个环境使用一个有效的 `dstva` 参数（低于 `UTOP`）去调用 `sys_ipc_recv` 时，环境将声明愿意去接收一个页映射。如果发送方发送一个页，那么那个页应该会被映射到接收者地址空间的 `dstva` 处。如果接收者在 `dstva` 已经有了一个页映射，那么已存在的那个页映射将被取消映射。
|
||||
|
||||
当一个环境使用一个有效的 `srcva` 参数（低于 `UTOP`）去调用 `sys_ipc_try_send` 时，意味着发送方希望使用 `perm` 权限去发送当前映射在 `srcva` 处的页给接收方。在 IPC 成功之后，发送方在它的地址空间中，保留了它最初映射到 `srcva` 位置的页。而接收方也获得了最初由它指定的、在它的地址空间中的 `dstva` 处的、映射到相同物理页的映射。最后的结果是，这个页成为发送方和接收方共享的页。
|
||||
|
||||
如果发送方和接收方都没有表示要转移这个页，那么就不会有页被转移。在任何 IPC 之后，内核将在接收方的 `Env` 结构上设置新的 `env_ipc_perm` 字段，以允许接收页，或者将它设置为 0，表示不再接收。
|
||||
|
||||
###### 实现 IPC
|
||||
|
||||
```markdown
|
||||
练习 15、实现 `kern/syscall.c` 中的 `sys_ipc_recv` 和 `sys_ipc_try_send`。在实现它们之前一起阅读它们的注释信息，因为它们要一起工作。当你在这些程序中调用 `envid2env` 时，你应该去设置 `checkperm` 的标志为 0，这意味着允许任何环境去发送 IPC 消息到另外的环境，并且内核除了验证目标 envid 是否有效外，不做特别的权限检查。
|
||||
|
||||
接着实现 `lib/ipc.c` 中的 `ipc_recv` 和 `ipc_send` 函数。
|
||||
|
||||
使用 `user/pingpong` 和 `user/primes` 函数去测试你的 IPC 机制。`user/primes` 将为每个质数生成一个新环境，直到 JOS 耗尽环境为止。你可能会发现，阅读 `user/primes.c` 非常有趣，你将看到所有的 fork 和 IPC 都是在幕后进行。
|
||||
```
|
||||
|
||||
```
|
||||
小挑战！为什么 `ipc_send` 要循环调用？修改系统调用接口，让它不去循环。确保你能处理多个环境尝试同时发送消息到一个环境上的情况。
|
||||
```
|
||||
|
||||
```markdown
|
||||
小挑战！质数筛选是在大规模并发程序中传递消息的一个很巧妙的用法。阅读 C. A. R. Hoare 写的 《Communicating Sequential Processes》，Communications of the ACM_ 21(8) (August 1978)， 666-667，并去实现矩阵乘法示例。
|
||||
```
|
||||
|
||||
```markdown
|
||||
小挑战！控制消息传递的最令人印象深刻的一个例子是，Doug McIlroy 的幂序列计算器，它在 [M. Douglas McIlroy，《Squinting at Power Series》，Software--Practice and Experience， 20(7) (July 1990)，661-683][4] 中做了详细描述。实现了它的幂序列计算器，并且计算了 _sin_ ( _x_ + _x_ ^3) 的幂序列。
|
||||
```
|
||||
|
||||
```markdown
|
||||
小挑战！通过应用 Liedtke 的论文（[通过内核设计改善 IPC 性能][5]）中的一些技术、或你可以想到的其它技巧，来让 JOS 的 IPC 机制更高效。为此，你可以随意修改内核的系统调用 API，只要你的代码向后兼容我们的评级脚本就行。
|
||||
```
|
||||
|
||||
**Part C 到此结束了。**确保你通过了所有的评级测试，并且不要忘了将你的小挑战的答案写入到 `answers-lab4.txt` 中。
|
||||
|
||||
在动手实验之前， 使用 `git status` 和 `git diff` 去检查你的更改，并且不要忘了去使用 `git add answers-lab4.txt` 添加你的小挑战的答案。在你全部完成后，使用 `git commit -am 'my solutions to lab 4’` 提交你的更改，然后 `make handin` 并关注它的动向。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://pdos.csail.mit.edu/6.828/2018/labs/lab4/
|
||||
|
||||
作者：[csail.mit][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[qhwdw](https://github.com/qhwdw)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://pdos.csail.mit.edu
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://pdos.csail.mit.edu/6.828/2018/labs/lab4/uvpt.html
|
||||
[2]: https://pdos.csail.mit.edu/6.828/2018/labs/readings/i386/toc.htm
|
||||
[3]: https://pdos.csail.mit.edu/6.828/2018/labs/readings/ia32/IA32-3A.pdf
|
||||
[4]: https://swtch.com/~rsc/thread/squint.pdf
|
||||
[5]: http://dl.acm.org/citation.cfm?id=168633
|
||||
@ -0,0 +1,77 @@
|
||||
四个开源的Android邮件客户端
|
||||
======
|
||||
Email 现在还没有绝迹，而且现在大部分邮件都来自于移动设备。
|
||||
|
||||
|
||||
|
||||
现在一些年轻人正将邮件称之为“老年人的交流方式”，然而事实却是邮件绝对还没有消亡。虽然[协作工具][1]，社交媒体，和短信很常用，但是它们还没做好取代邮件这种必要的商业（和社交）通信工具。
|
||||
|
||||
考虑到邮件还没有消失，并且（很多研究表明）人们都是在移动设备上阅读邮件，拥有一个好的移动邮件客户端就变得很关键。如果你是一个想使用开源的邮件客户端的 Android 用户，事情就变得有点棘手了。
|
||||
|
||||
我们提供了四个开源的 Andorid 邮件客户端供选择。其中两个可以通过 Andorid 官方应用商店 [Google Play][2] 下载。你也可以在 [Fossdroid][3] 或者 [F-Droid][4] 这些开源 Android 应用库中找到他们。（下方有每个应用的具体下载方式。）
|
||||
### K-9 Mail
|
||||
|
||||
[K-9 Mail][5] 拥有几乎和 Android 一样长的历史——它起源于 Android 1.0 邮件客户端的一个补丁。它支持 IMAP 和 WebDAV、多用户、附件、emojis 和其他经典的邮件客户端功能。它的[用户文档][6]提供了关于安装、启动、安全、阅读和发送邮件等等的帮助。
|
||||
|
||||
K-9 基于 [Apache 2.0][7] 协议开源，[源码][8]可以从 GitHub 上获得. 应用可以从 [Google Play][9]、[Amazon][10] 和 [F-Droid][11] 上下载。
|
||||
|
||||
### p≡p
|
||||
|
||||
正如它的全称，”Pretty Easy Privacy”说的那样，[p≡p][12] 主要关注于隐私和安全通信。它提供自动的、端到端的邮件和附件加密（但要求你的收件人也要能够加密邮件——否则，p≡p会警告你的邮件将不加密发出）。
|
||||
|
||||
你可以从 GitLab 获得[源码][13]（基于 [GPLv3][14] 协议），并且可以从应用的官网上找到相应的[文档][15]。应用可以在 [Fossdroid][16] 上免费下载或者在 [Google Play][17] 上支付一点儿象征性的费用下载。
|
||||
|
||||
### InboxPager
|
||||
|
||||
[InboxPager][18] 允许你通过 SSL/TLS 协议收发邮件信息，这也表明如果你的邮件提供商（比如 Gmail ）没有默认开启这个功能的话，你可能要做一些设置。（幸运的是， InboxPager 提供了 Gmail的[设置教程][19]。）它同时也支持通过 OpenKeychain 应用进行 OpenPGP 机密。
|
||||
|
||||
InboxPager 基于 [GPLv3][20] 协议，其源码可从 GitHub 获得，并且应用可以从 [F-Droid][21] 下载。
|
||||
|
||||
### FairEmail
|
||||
|
||||
[FairEmail][22] 是一个极简的邮件客户端，它的功能集中于读写信息，没有任何多余的可能拖慢客户端的功能。它支持多个帐号和用户，消息线程，加密等等。
|
||||
|
||||
它基于 [GPLv3][23] 协议开源，[源码][24]可以从GitHub上获得。你可以在 [Fossdroid][25] 上下载 FairEamil； 对 Google Play 版本感兴趣的人可以从 [testing the software][26] 获得应用。
|
||||
|
||||
肯定还有更多的开源 Android 客户端（或者上述软件的加强版本）——活跃的开发者们可以关注一下。如果你知道还有哪些优秀的应用，可以在评论里和我们分享。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/10/open-source-android-email-clients
|
||||
|
||||
作者：[Opensource.com][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[zianglei][c]
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com
|
||||
[b]: https://github.com/lujun9972
|
||||
[c]: https://github.com/zianglei
|
||||
[1]: https://opensource.com/alternatives/trello
|
||||
[2]: https://play.google.com/store
|
||||
[3]: https://fossdroid.com/
|
||||
[4]: https://f-droid.org/
|
||||
[5]: https://k9mail.github.io/
|
||||
[6]: https://k9mail.github.io/documentation.html
|
||||
[7]: http://www.apache.org/licenses/LICENSE-2.0
|
||||
[8]: https://github.com/k9mail/k-9
|
||||
[9]: https://play.google.com/store/apps/details?id=com.fsck.k9
|
||||
[10]: https://www.amazon.com/K-9-Dog-Walkers-Mail/dp/B004JK61K0/
|
||||
[11]: https://f-droid.org/packages/com.fsck.k9/
|
||||
[12]: https://www.pep.security/android.html.en
|
||||
[13]: https://pep-security.lu/gitlab/android/pep
|
||||
[14]: https://pep-security.lu/gitlab/android/pep/blob/feature/material/LICENSE
|
||||
[15]: https://www.pep.security/docs/
|
||||
[16]: https://fossdroid.com/a/p%E2%89%A1p.html
|
||||
[17]: https://play.google.com/store/apps/details?id=security.pEp
|
||||
[18]: https://github.com/itprojects/InboxPager
|
||||
[19]: https://github.com/itprojects/InboxPager/blob/HEAD/README.md#gmail-configuration
|
||||
[20]: https://github.com/itprojects/InboxPager/blob/c5641a6d644d001bd4cec520b5a96d7e588cb6ad/LICENSE
|
||||
[21]: https://f-droid.org/en/packages/net.inbox.pager/
|
||||
[22]: https://email.faircode.eu/
|
||||
[23]: https://github.com/M66B/open-source-email/blob/master/LICENSE
|
||||
[24]: https://github.com/M66B/open-source-email
|
||||
[25]: https://fossdroid.com/a/fairemail.html
|
||||
[26]: https://play.google.com/apps/testing/eu.faircode.email
|
||||
Loading…
Reference in New Issue
Block a user