小灰笔记

这个是我的树莓派现在的一个状态，这个树莓派的配置一应该是1GB内存，但是从这里的922M以及922M + 100得到的1022M似乎都不是很准确。结合上面的信息，或许树莓派的RAM大小应该是1024MB，之所以算出来不是这些是因为上面的解释中，Total部分其实是去掉了一些保留位以及系统的部分占用？我现在常用的一个小主机其实是我的树莓派3B，虽然算不上多么高的配置，家用还是很适合的。结合这两个参数的描述，如果使用-h的选项的时候独到的数据应该是按照1024作为对应的进制来衡量的。

程序的分离涉及到的一个很重要的问题点就是分离后的各个模块之间的通信，前面考虑到了管道、信号等不同的形式，但是有一个很大的短板：信号的流向是单向的。前面的很多技术考虑的方法都是协议或者机制，但是从实时性以及快速性的角度考虑，数据的共享以及交换通过一块可以多方一起访问的内存来实现也是一个方式。类似的，这种处理的形式在嵌入式的程序中似乎也有这样的影子。如果是考虑有共享数据的存在，不同的任务甚至CPU之间的数据的同步在一致性上就得有独到的设计。如果是在性能要求敏感的设计中，这样的操作会比较低效。

但是，从这里的说明我们还是可以得到一些软件实现上的借鉴的。其实，现在比较流行的汽车电子的软件开发架构AUTOSAR中是有一个DET的功能的，这个就是非常好的一个设计体现。软件设计的时候要从可维护的角度做充分的思考。”如果按照这样的观点或者原则设计出来的代码，或许在可读性以及可维护性上会有非常好的表现。做一个简单的小结，从一个软件工程师的角度来看看透明性以及可显性的概念和作用。因为很多人的软件设计我称之为是漫游式的，很难看得出来层级的关系。这个是对透明性以及可显性的功能作用的一个基本描述。

从信息传递的角度，我理解这个是便于信息传递与解读的，而从维护的角度也理解这样做其实是方便使用各种文本编辑工具来查看和维护的。从这么多年来工作积累的根深蒂固的经验角度思考，除了调试，如何来让这种文本化的理念应用到这种非unix系统的平台之上。关于这一点描述的确是很有感触，python等脚本语言中的列表、字典等设计的确是在做数据处理的时候很好的帮手。我之所以在过去的工作中很少遇到这样的问题，并不是说这样的处理情况不存在，而是控制类的嵌入式软件设计中这种情况遇到的相对较少。

这方面，在我接触到的嵌入式里面应该是没有的。UNIX的一些思想在嵌入式的软件设计中似乎也有一些可以借鉴或者引发我们思考的地方，当然，这个可能并不能百分百的做借鉴。行业技术的发展其实很多时候会在印证技术方案的合理性，UNIX的方式在实时的控制领域虽然也有QNX这样的应用，但是控制类的期间大部分还并不是这种技术方案。从这样的角度看，至少行业的经验已经弄清楚，UNIX的方案在这个领域并不是百分百的可行。OS的设计其实是提供一个平台化的东西，更加标准化，为更高一级的软件的设计提供一个统一的环境和合理高效的机制。

使用的时候也一定会有一个比较好的实践方式。按照这样的一个经验设计，或许一个接口的代码行数以及实际的物理行数（我理解应该是包含了注释以及空白的行数）应该都有一个推荐的数制。当然，我考虑这样的建议是建立在一个假设的前提上的：其实我看到新手的注释写的还是很少的。但是，在背负了这么多的抽象包袱之后，一个很麻烦的问题来了：几乎所有的软件开发人员，无论是底层、中间层、接口层或者是应用软件的开发人员可能没有谁能够完整地理解系统的根本原理。当我在工作的过程中看到很多新手写的代码的时候，这通常是我经常想到的一个尝试的工作。

由此可以看得出来，技术或者工程的角度有时候无法容忍完美主义者，市场竞争的环境中传导的压力可能会让可用性、时效性的作用在优胜劣汰的过程中进行无限的放大。类似这样的产品，在整个维护的过程中肯定有很多技术积淀，后来这样的技术成果又是通过什么样的途径让未来的产品对其进行继承的？从他们的历史来看，其实很多系统的生存期跟我所熟悉的年代是重合的，但是我却从来没有感受到过他们的存在。如果过于纯粹，或许就是BeOS的结果，即便是我们能够极尽所能完成自己追求的技术实施，但是很可能会失去被市场认可的机会。

如果是类似于顺序加载的情况，或者是协同式的任务处理，那么用户在处理多个大型任务的时候或许会觉得有一些任务在一定的时间范围内没有什么处理的进展。不过，这种设计似乎又跟我接触到的RTOS的设计有所不同，我接触到的RTOS都有一个tick，它们会借助于这个tick来管理很多时间概念。其实，RTOS，尤其是嵌入式的RTOS在使用场景上跟我们PC或者server所要处理的内容有着比较大的差异。由于这样的一个区分度，其实我倒觉得类似于DOS这样的顺序加载器在一定程度上考虑其实或许还是适用于某些嵌入式的控制的。

3. 不过，如果这样的开发模式也跟Arduino类似，有一个BootLoader已经固化在里面，而开发只是简单的通信传输升级就可以调试，这样其实就很通用了。不过，从描述的信息看，下载的不是IDE的信息而是一个编译环境。3. 这个环境实现的接口相比Arduino来说是更加简洁的，而且由于ARM本身的设计，在这样的环境上容易扩展更多的支持，比如说网络的支持。但是，Arduino的有点在于经过了这么多年的打磨之后，实现的库比较多。1. 这个IDE是可以在网页上使用的，使用的时候，目标板会在电脑中显示为存储。

在实验室目录的顶层，在一个名为answers-lab3.txt的文件中，写下对实验室中提出的问题的简短回答，并用一两段话描述你为解决所选挑战问题所做的事情。在英特尔的术语中，中断是一种受保护的控制传输，由通常在处理器外部的异步事件引起，例如外部设备I/O活动的通知。在JOS内核中，我们将使用int指令，这会导致处理器中断。处理器需要一个地方来保存中断或异常发生前的旧处理器状态，例如处理器调用异常处理程序前EIP和CS的原始值，以便异常处理程序稍后可以恢复旧状态，并从中断的地方恢复中断的代码。

来到北京工作，工作原因又用了将近一年的Windows，前阵子因为后台自动升级把电脑给正的崩盘，无奈下又用CentOS。好的是，我安装的全功能开发者版本，很多工具都已经安装齐全，至少我作开发测试或者学习用的工具基本上不用额外增加。坚持使用了多年，我发现它能够给我想要的全部功能，同时我不想要的功能也有很多被天然性地排除在了外面。无奈之下，继续回到火狐引导的下载网站，这次下载的rpm文件。后来又选择用了几个月的CentOS，我对这个系统也有很大的期待，因为直觉上我觉得这个系统的稳定性一定会好过Ubuntu。

我没哟买Windows 10的系统，我也不想把自己买的Windows 7升级的乱七八糟。后续自己的文档积累会越来越充足，慢慢的我自己的日记都会考虑采用电子文档的模式。不过，现在的现实境况中，纸笔还是我少不了的东西。利用杠杆效应是我需要考虑的一点，我现在处理什么东西的时候考虑的方式通常还是自己写工具。如果能够利用别人的成果那也是一个很好的选择，可惜的是现在的公司封闭根本没有网络可用。比如不再考虑写一个冗长的程序转而考虑写不超过100行的程序，100行是Perl学习的时候书中推荐的一个长度。

Linux系统的硬件需求相对来说是比较低的，这些年Linux的使用者越来越多跟很多老旧的硬件因为Linux的存在继续发挥预热有关。还有重要的一点是费用低廉，很多发行版或者说是绝大多数的发行版现在都是免费的，而技术服务支持的资料不仅多而且讲解深度也高。如果所谓的万能驱动包解决不了你硬件驱动的问题，那很可能意味着你的显卡等原本火力十足的武器一下子被打回到解放前的水准。总算是在书中接触到了什么是UNIX的思想，Ken在最初设计UNIX的时候有两个基本的思想：第一，所有的程序或者系统装置都是文件；

虚拟机的下拉列表中选择安装VMware Tools（我已经安装好了这里面的显示便已经发生了变化，只有重新安装的选项），之后能够在Ubuntu中发现自动加载了一个虚拟出来的光驱。中间当然也会看到一个让人高兴的提示，会有拖拽功能的提供，我们当然没道理不把这个功能启用，这才是简单方便的文件共享。可是那时候的我确实是少了那么一份执着的探索精神，现在可不是同样的状态了。最终还是放弃了，应该会有很简单的方式也有丰富的网络教程，但是我上网并不是很方便，在流量金贵的条件下想着自己折腾或许是比较好的一种方式。

KDE是我用过时间最短的一个桌面，这个界面的使用习惯非常适合习惯了Windows的人上手，据说Linus最喜欢的也是这个桌面环境。这种牛皮癣的特性似乎也成了我讨厌它的一个借口。不过，根据我个人的体验，我觉得这是我用过的桌面环境中跟Ubuntu兼容性最不好的一个。不过，我相信很多人的看法：KDE是一个不错的桌面环境，令人不好接受的是它在Ubuntu下的兼容性不是很好。当然，我现在都觉得那是我见过的最美的官方默认系统中用到的Gnome，Fedora的美丽图标好过了Ubuntu，没有Ubuntu的那种凌乱感。

不可否认，我很喜欢漂亮的界面，如果手头的电脑是mac，我想我转投苹果阵营是板上钉钉的结果。说到了批处理，说到了调用的自动化等等东西，我想接触过Linux的人全都不会记不起这个系统，也不会想不起shell。While循环的意思还是很明显的，为了习惯我自己的阅读习惯，我对代码的缩进排版也做了一点点调整。下载了一本500页的shell教程，看了50页后决定放弃，更好的方式是凭借自己的直觉加网络搜索的方式学习。跋：看了一下，这个可能是我大约十年前的学习笔记了，脑海中都没有多少那时候的记忆痕迹了。

然而，在现在科技进步如此迅速的时代，总会有一种方法会让我们找到完成同样工作的方法，这种方法可以脱离Windows这个吸金的操作系统。我觉得Linux的不断发展以及全世界各地程序猿、攻城狮们的努力会让我们获得我们想要的，根据我的经验，通常这种新的方式会让我知道什么叫做自由和高效。由于工作性质的原因吧，我电脑上太多的文件，有时候各种命名规范的要求下文件名字也变得超长。我觉得在Linux操作系统上折腾可以给我这种生命仍在燃烧的感觉，原因说不清楚，可能是自己东拼西凑的东西还是能够给自己一点成就感吧！

想学习一下perl，当前很想做的一件事儿是使用perl在脱离了windows以及微软的office依然能够构建出简单有效的自动化脚本。现在我正在使用LibreOffice编写我的博客文稿，因为我想体验简单。但是闲得无聊的时候这是一个好事儿，因为我又有东西要学习了。苦闷的生活有时候真的跟成长的岁月是同义词，我自己现在正在很好的体会。终于让我找到了比较简单带点傻瓜式的安装方法了，简单的命令之后自动搞定。依我自己的个人直观加表象的理解，第一行应该是进入CPAN的shell，接下来的两行则是安装两个必要的块儿。

其实，这里也埋下了一个bug，那就是如果是这么初始化的话，只要是OS运行的时间足够长，这个alarm其实一定会触发。我考虑的方式是直接增加一个初始化的使能参数，而网络上参考了一下其他人的设计其实大部分设计都是采用了带有符号的数据类型初始化的时候给一个负值。这样，一个基本的框架就实现了，具体的alarm的触发还得继续设计。这里的判断条件信息在要求附加的提示信息中都已经给出来了，如果上面的alarmticks具有正负号的话，的确是能够保证这里不会出现误触发。与之对应的，增加这个系统调用的查询表。

如果应用程序调用alarm(n, fn)，那么在程序消耗的CPU时间的每n个“滴答”之后，内核将导致调用应用程序函数fn。可选的挑战：1）保存和恢复调用方保存的用户注册到处理程序的调用。而这个概念其实在我现在使用的RTOS中也是有的，至于这个Alarm在底层的实现机制是什么样子的，之前的确是没有研究过。提示：您的sys_alarm（）应该将报警间隔和指向处理程序函数的指针存储在proc结构中的新字段中；提示：在您的IRQ_TIMER代码中，当进程的alarm间隔到期时，您希望让它执行其处理程序。

这个是对之前延时分配的一个说明，这里提到了trap类型中有一个页错误的类型，这个之前在做xv6的代码调试的时候已经看过了，也做了这样的尝试。这一段代码之前我已经自己分析过了，这个是一个较为常规的trap发生的时候的堆栈处理模型。Fork的效率也有优化的空间，可以通过使用的时候才分配的方式避免分页浪费且提升效率。这一段代码也是很熟悉的，之前做系统调用的分析的时候分析过这一段代码的实现以及作用。可以通过共享的方式，减少这方面的资源消耗。相比我自己的实现，这里增加了一个进程信息的检查，设计的确是更加完善的。

这里的分类可以从trap.h中看到，这里定义了用到的所有的分类。代码的修改方法如上，这里我直接加了一个break，这样相当于把后面的这段提示直接给毙掉了。前面刚刚把《Homework xv6 lazy page allocation》的网页做了一个简单的翻译整理，这一次做一下里面的试验尝试。这样修改之后，测试出来的效果与前面的修改方式是一致的。这一次的实现增加了一个case，而这里增加大括号的原因是能够在这里划分出来一个代码块以进行变量定义的处理。参考这里的两点要求，实现上面的修改就非常简单了。

全部学习汇总：在计划表中看到了这样一份作业，做一个简单的翻译整理。

分析一下xv6的构建环境会发现，其实这个功能的实现是基于unix系统中的C语言来实现的。直接通过C语言设计工具在makefile中调用，这不是第一次看到了，另一次是在看FUZIX代码的时候看到的。的确是非常巧妙，也足以让我去好好反思一下，为什么类似的处理在我的工作中就很难联想到。代码前面也写了非常有用的注释可以让我们知道，在处理文件到文件系统的时候，这个前面的前缀是被处理掉了的。这一次看一下，如何让OS的系统中增加这样的一个可执行的文件。系统启动之后，多了一个date文件，这个跟我们的命令是对应的。

由此，用户软件命令中的操作，其实就成了传递r的信息参数，之后由上面的系统实现进行数据更新的过程。有了这样的参数信息的获取之后，我们的OS内核就可以跟用户级的软件信息产生交互了。从这里可以知道，这个date.c的实现是如何进入到xv6中产生对应的作用的。上面的系统调用部分中，syscall()接口的调用是触发我们系统中C语言实现的调用接口的地方。上面的接口的实现，主要是做了一个数据过滤，真正的获取动作来自于argint()接口。而这个查表处理的表格则是我们系统设计中提供给系统的可以执行的系统调用的具体实现。

这里需要说明一下的是编译环境的搭建，我这里采用的跟JOS的环境完全相同的虚拟机，因此整个环境是完全相同的。不过，看makefile中的信息，qemu的目录还是Mac上的。为保证启动的顺利，先修改了qemu的路径，这个路径需要跟我们系统上的工具路径一致。那么，处理的方式很简单了，上面的代码屏蔽。6.828的学习的资料从开始基本信息的讲解，逐步往unix的一个特殊版本xv6过度了。我这里复现了一下出现的问题，由于其他文件都是已经编译过的，因此这里的log会跟拿过来的原始的编译的log略有差异。

找一下对等的功能在xv6中是如何实现的，顺便看看xv6的一些其他的信息。从这里的注释以及实现看，前面的猜测，kalloc分配的是一个page的存储是准确的。从这个接口以及前面的调用的参数基本上知道，在初始化的时候先进行了4MB的空间初始化用于内核最初的使用。这里实现了内核的虚拟存储的配置，从行为看，kalloc可能是直接分配了一个page的存储，之后进行了初始化。这是页目录的定义，正好由此看一下关键参数KERNBASE，因为其他的应该都是一致的套路，然而也看到了这里的初始化用了不同的方法。

全部学习汇总： GreyZhang/g_unix: some basic learning about unix operating system. (github.com) 说明：这一份笔记是我对xv6-book-rev11第二章节的翻译整理。翻译的主要方式就是机器翻译，我对其中阅读有一些障碍性或者有较大误导性的地方做了修正。这份笔记是为了能够让我更好理解这一部书而整理的，而本章节并不是从最开头准备的。 以下是部分翻译的正文：Xv6包含了内核在每个进程的页表中运行所需的所有

其实从这一页前半段就能够看得出来，中断的处理其实都是内核托管的，由内核来处理。1. 关于中断的处理，感觉上全都是由内核来托管的。而用户触发的相应的中断会在内核处理，而接下来的操作只有对应的用户可以承接。6. 我现在接触的很多嵌入式的MCU其实也有类似的机制，更加直接地从访问模式上分为了用户以及管理员模式。3. 这一页也介绍了芯片对于中断的处理机制，这个我觉得不同芯片都是类似的，我也看过很多芯片的类似功能。3. 隔离的主要作用：防止错误的扩散、进程之间的相关监控、过多的CPU占用以及一些异常行为的阻断。

这是修改后的代码进行测试的结果，从这里看暂时有提示的测试全都已经测试通过。之前把这一部分相关的功能全都调试通过了，从这里的注释看，其实这里的准备更多的是为了画出来的两个接口。其中，page_insert()已经在前面的调试中实现了，接下来看一下boot_map_region()的实现。完成了上面的接口之后，做这个接口的实现就会简单很多。但是，在做这个实现的时候，第一个参数的确认费了点时间。这个接口应该只是在初始化的阶段在用，按理说也不会有存储超出的情况，不过加上总没坏处。这里，完成了剩余的存储的映射。

这个函数接受三个参数：pgdir是一个指向页目录表的指针，va是要查找的虚拟地址，create表示如果要查找的页表不存在是否要创建。最后，使用虚拟地址KADDR(PTE_ADDR(xxx))将页表的物理地址映射到内核虚拟地址空间，并返回指向相应页表的pte_t类型指针，加上va低12位作为页表项的索引。这个函数接受三个参数：pgdir是一个指向页目录表的指针，va是要查找的虚拟地址，pte_store是一个指向指针的指针，用于保存对应的页表项。确切说，这个查找查找的是虚拟地址对应的物理page的信息。

更重要的一点，这里还给出来了用到的接口。继续看这个页面分配的检查接口，在检查完了页面的分配以及回收之后，进一步检查了对于分配的存储的写入操作。单纯的一个页面的释放占用还是很容易实现的，不过按照这里的提示这里加了一个panic防止出现占用中的存储被释放的情况。这个链表的元素数目在最开始的时候进行了一个统计，这里通过统计一个丢弃一个的方式完成了“蜕壳”处理。处理完之后的测试，从测试的结果看到存储分配以及回收部分的测试现在是通过了。这是最初的处理，尤其值得注意的是这里的操作是在链表出现变化之前的操作。

这个其实是在前面初始化的时候分配出来的一块存储，接着进行了页管理信息的初始化。那么，这个函数实现的是按照页信息相对于pages的基地址的偏移来找到对应的物理地址，而这个跟真实的物理地址是一一对应的关系。由此，从上面的逻辑运算中，能够计算出来的其实是对应的页面管理信息所映射的物理存储的页开始地址。进行存储分配的时候，返回的应该是开始的地址而不是结束的地址。接下来的检查倒是比较容易让人理解，主要还是检查了一些存储的边界范围是否在合理的范围之内。以上是执行效果，从这一次的效果看很明确，之前的存储分配有问题。

继续往下的分析，应该暂停下面接口的分析，先去把上面提到的boot_map_region()以及page_insert()接口的实现。这里的这部分注释比较有价值，值得注意的有几点：第一，pages的信息主要是对引用的页面进行统计，而没有引用的界面则在链表中进行维护；这个是按照上面的4条要求做的一个简单的设计实现，其中结构体的pp_ref成员可能有多种数值，但是当这个数值为0的时候应该是没有被引用的时候，这个也是最初给出来的示范代码的设计。这一次的梳理暂且到此，后面，先完成上面两个接口的实现与分析。

这一行代码让分页管理的机制处理kern_pgdir虚拟地址的时候，把kern_pgdir的地址映射到kern_pgdir的物理地址上。这一次的小结有一点没底气，因为感觉实现的过于简单，可能跟正确的结果有一定的差距。这一段代码其实还是很容易理解的，end其实是链接文件中定义的，这个数值其实是内核所占用的存储的最后的地址。Panic的地址范围判断应该是KERNBASE空间之后的超过总的物理存储区的时候。PDX(UVPT)是一个获取页目录索引的方式，而处理的对象UVPT是用户虚拟页表，一个用户只读的用户页表。

这个空间的看见，看了前面的memlayout感觉也有了一定的思维模型可以参考了。而上面涉及到了这次调用中的第一个接口调用，i386_detect_memory()，这是一个很底层的判断，用来检查当前的系统可用的存储。首先需要知道的是KVA，内核虚拟地址的范围。这个地址其实就是软件编译之后链接器分配的地址，JOS把内核的部分分配到了KERNBASE + 1MB的位置。因此，上面的处理所获得的物理地址其实是一个1MB开始往后的地址。这样，可以想得出来，后续kern_pgdir的内容还是需要进行一定的处理的。

接下来的几个特殊区域是两个区。第一个4MB之中包含了USTABDATA，其实是从2MB的位置开始的，这只用掉了这一个大区中的一部分。而第二个区域中，错误处理其实用掉的空间比较小，只有一个页，4K，其他的全都是交换区应用。在用户可以完全操作的存储空间中，最上面先进行了 exception 的处理存储区域的划分，这个存储区域一共是2页 8K，实际的使用使用了4K，另外的一半处理机制跟上一次看到的内核的堆栈类似，加了一个无效数据区域作为防护区。之前，看到的UENVS的信息，这个地址是用户的只读区域的边界线了。

因为，我们的JOS在初始化的时候映射的存储只有两部分，第一个是0~4MB映射到0~4MB。中间跳过去的这部分参数其实很好理解了，在x86的设计中，最开始的一块地址是存储，一共640K。如果按照之前看到的OS的分页映射，这部分的线性地址其实是在KERNBASE开始的1MB范围之内。但是，这部分内容更加细致，除了说明用户的存储空间可用范围之外，还指出来了这里还有一些特殊的用户只读的信息区域。操作系统其实是被链接到了KERNBASE + 1MB的地址上的，也就是说从画出来的这部分继续向上的一部分空间中。

而这个无限循环的循环体，应该就是shell处理的过程，大概率跟我之前看到过的shell例程是相似的。存储的区间范围信息的获取，其实是通过链接文件来实现的。在BootLoader调用kernel之后，先执行一段entry.S的汇编代码，之后调用的i386_init函数进入到C语言的处理过程。这个之前已经测试过了，而通过前面的终端初始化中的错误处理其实是能够看得出来这个cprintf已经就绪了的。继续往下是存储的初始化，这部分已经做了一个初步的了解，主要的工作就是对存储的分页管理机制进行相应的配置准备。

如果，进行了一个减去KERNBASE的处理，其实里面的信息也就是在1MB这个地址附近，确切说是这个地址稍微往后一点的地方。这么看，在数值上entry_pgdir的第0个元素的数值应该是entry_pgtable数组在被BootLoader加载到物理存储之后的位置的一个字节之后的地址值。而这里面的第0x3c0个元素的数值则是比上面的数值再大2的一个数值。这样，对这段代码重新理解应该能够得出这样的基本推理信息：页目录表的index其实是需要处理的线性地址的高10bit，根据这个信息，可以索引到一个信息。