## 简要介绍



这是一个免费的类 minix 内核，适用于基于 i386(+) 的 AT 机器。包含完整源代码，并且已在两台不同的机器上生成了可运行的内核。目前没有公开的内核二进制文件，因为它们需要针对不同的机器重新编译。您需要使用 gcc 编译它（我使用1.40，不知道1.37.1是否会处理所有的‘ asm ’指令）

## 版权声明



遗憾的是，单靠内核并不能解决问题。要获得一个可以运行的系统，你需要一个 shell、编译器、库等等。这些都是独立的部分，可能受到更严格（甚至更宽松）的版权保护。Linux 使用的大多数工具都是 GNU 软件，并且受 GNU Copyleft 保护。这些工具不在发行版中——更多信息请咨询我（或 GNU）。

##  简要的技术一览

没有消息传递，这是 Unix 更传统的实现方式。系统调用就是调用。这可能会更快，也可能不会，但这确实意味着我们可以省去一些与消息（消息队列等）相关的问题。当然，我们也错过了一些很棒的功能 :-p。

```
Multithreaded FS - a direct consequence of not using messages.  
	  This makes the filesystem a bit (a lot) more complicated, but  
	  much nicer. Coupled with a better scheduler, this means that  
	  you can actually run several processes concurrently without  
	  the performance hit induced by minix.
	多线程文件系统 - 这是不使用消息机制的直接结果。这使得文件系统稍微（很多）复杂了一点，但也更加友好。再加上更好的调度程序，这意味着你可以同时运行多个进程，而不会像 minix 那样受到性能影响。
```
```
- Minimal task switching. This too is a consequence of not using
	  messages. We task switch only when we really want to switch
	  tasks - unlike minix which task-switches whatever you do. This
	  means we can more easily implement 387 support (indeed this is
	  already mostly implemented)- 最小化任务切换。这也是不使用消息的结果。我们只在真正需要切换任务时才进行任务切换——不像 minix，它会根据你的操作自动切换任务。
```

```
- Interrupts aren't hidden. Some people (among them Tanenbaum)
	  think interrupts are ugly and should be hidden. Not so IMHO.
	  Due to practical reasons interrupts must be mainly handled by
	  machine code, which is a pity, but they are a part of the code
	  like everything else. Especially device drivers are mostly
	  interrupt routines - see kernel/hd.c etc.- 中断没有被隐藏。有些人（其中包括 Tanenbaum）认为中断很丑陋，应该被隐藏。在我看来并非如此。由于实际原因，中断必须主要由机器码处理，这很可惜，但它们和其他所有东西一样，都是代码的一部分。尤其是设备驱动程序，它们大多是中断例程——参见 kernel/hd.c 等。
```

```
- There is no distinction between kernel/fs/mm, and they are all
	  linked into the same heap of code. This has it's good sides as
	  well as bad. The code isn't as modular as the minix code, but
	  on the other hand some things are simpler. The different parts
	  of the kernel are under different sub-directories in the
	  source tree, but when running everything happens in the same
	  data/code space.- 内核/文件系统/内存管理之间没有区别，它们都链接到同一堆代码中。这有好有坏。代码不像 minix 代码那样模块化，但另一方面，有些部分更简单。内核的不同部分位于源代码树的不同子目录中，但运行时，所有操作都发生在同一个数据/代码空间中。
```

```
- Just one data structure for tasks. "Real" unices have task
	  information in several places, I wanted everything in one
	  place.- 任务只有一个数据结构。“真正的”unices 会在多个地方保存任务信息，我希望所有信息都集中在一个地方。	
- A very simple memory management algorithm, using both the
	  paging and segmentation capabilities of the i386. Currently
	  MM is just two files - memory.c and page.s, just a couple of
	  hundreds of lines of code.- 一个非常简单的内存管理算法，同时使用了 i386 的分页和分段功能。目前 MM 只有两个文件——memory.c 和 page.s，只有几百行代码。
```

## 狭义上的内核

`proper:[ after noun]according to the most exact meaning of the word严格意义上的；狭义的`



```
All the routines handling tasks are in the subdirectory "kernel". These
include things like 'fork' and 'exit' as well as scheduling and minor
system calls like 'getpid' etc. Here are also the handlers for most
exceptions and traps (not page faults, they are in mm), and all
low-level device drivers (get_hd_block, tty_write etc). Currently all
faults lead to a exit with error code 11 (Segmentation fault), and the
system seems to be relatively stable ("crashme" hasn't - yet).所有处理任务的例程都位于子目录“kernel”中。这些例程包括“fork”和“exit”之类的函数，以及调度和诸如“getpid”之类的小型系统调用。此外，这里还包含大多数异常和陷阱（不是页面错误，它们以毫米为单位）的处理程序，以及所有底层设备驱动程序（get_hd_block、tty_write 等）。目前，所有错误都会导致以错误代码 11（段错误）退出，系统似乎相对稳定（“crashme”暂时没有出现）。
```

## 内存管理

```
This is the simplest of all parts, and should need only little changes.
It contains entry-points for some things that the rest of the kernel
needs, but mostly copes on it's own, handling page faults as they
happen. Indeed, the rest of the kernel usually doesn't actively allocate
pages, and just writes into user space, letting mm handle any possible
'page-not-present' errors.
这是所有部分中最简单的，应该只需要很少的改动。它包含内核其他部分所需的一些入口点，但大多数情况下它自己处理，在发生页面错误时进行处理。实际上，内核的其余部分通常不会主动分配页面，而只是写入用户空间，让 mm 处理任何可能的“页面不存在”错误。Memory is dealt with in two completely different ways - by paging and
segmentation.  First the 386 VM-space (4GB) is divided into a number of
segments (currently 64 segments of 64Mb each), the first of which is the
kernel memory segment, with the complete physical memory identity-mapped
into it.  All kernel functions live within this area. 
内存处理有两种截然不同的方式——分页和分段。首先，386 虚拟机空间（4GB）被划分为多个段（目前为 64 个段，每个段 64MB），其中第一个是内核内存段，完整的物理内存都以身份映射的方式映射到该段中。所有内核函数都位于此区域内。Tasks are then given one segment each, to use as they wish. The paging
mechanism sees to filling the segment with the appropriate pages,
keeping track of any duplicate copies (created at a 'fork'), and making
copies on any write. The rest of the system doesn't need to know about
all this.
每个任务都会被分配一个段，供它们随意使用。分页机制负责用合适的页面填充该段，跟踪任何重复的副本（在“fork”处创建），并在任何写入操作时创建副本。系统的其余部分无需了解所有这些。
```

## 文件系统

```
As already mentioned, the linux FS is the same as in minix. This makes
crosscompiling from minix easy, and means you can mount a linux
partition from minix (or the other way around as soon as I implement
mount :-). This is only on the logical level though - the actual
routines are very different.如前所述，Linux 文件系统与 Minix 中的相同。这使得在 Minix 中进行交叉编译变得容易，并且意味着您可以从 Minix 挂载 Linux 分区（或者，在我实现挂载功能后，反过来也可以 :-)。不过，这只是逻辑层面上的不同——实际操作过程截然不同。	NOTE! Minix-1.6.16 seems to have a new FS, with minor
	modifications to the 1.5.10 I've been using. Linux
	won't understand the new system.注意！Minix-1.6.16 似乎有一个新的文件系统 (FS)，与我一直在使用的 1.5.10 版本相比略有修改。Linux 无法识别这个新系统。The main difference is in the fact that minix has a single-threaded
file-system and linux hasn't. Implementing a single-threaded FS is much
easier as you don't need to worry about other processes allocating
buffer blocks etc while you do something else. It also means that you
lose some of the multiprocessing so important to unix.主要区别在于 minix 有一个单线程文件系统，而 Linux 没有。实现单线程文件系统要容易得多，因为您无需担心在您执行其他操作时其他进程分配缓冲区块等。这也意味着您会失去一些对 Unix 至关重要的多处理功能。There are a number of problems (deadlocks/raceconditions) that the linux
kernel needed to address due to multi-threading.  One way to inhibit
race-conditions is to lock everything you need, but as this can lead to
unnecessary blocking I decided never to lock any data structures (unless
actually reading or writing to a physical device).  This has the nice
property that dead-locks cannot happen. 由于多线程，Linux 内核需要解决许多问题（死锁/竞争条件）。抑制竞争条件的一种方法是锁定所有需要的数据结构，但由于这会导致不必要的阻塞，所以我决定永远不锁定任何数据结构（除非实际读取或写入物理设备）。这样做的好处是不会发生死锁。Sadly it has the not so nice property that race-conditions can happen
almost everywhere.  These are handled by double-checking allocations etc
(see fs/buffer.c and fs/inode.c).  Not letting the kernel schedule a
task while it is in supervisor mode (standard unix practise), means that
all kernel/fs/mm actions are atomic (not counting interrupts, and we are
careful when writing those) if you don't call 'sleep', so that is one of
the things we can count on.遗憾的是，它有一个不太好的特性，那就是竞争条件几乎随处可见。这些可以通过双重检查分配等来处理（参见 fs/buffer.c 和 fs/inode.c）。在管理模式下不让内核调度任务（这是 Unix 的标准做法），意味着如果不调用“sleep”，所有 kernel/fs/mm 操作都是原子的（不包括中断，我们在编写中断时非常谨慎），所以这是我们可以信赖的事情之一
```

https://ftp.funet.fi/pub/linux/historical/kernel/old-versions/RELNOTES-0.01