操统实验日志 第一章 序章
简述
+操统实验日志 第一章 序章
简述
在一切开始之前，请允许我先简要地介绍一下关于这个实验的一切
它是关于什么的
@@ -506,7 +506,7 @@ btf.addGlobalFn('pjaxSend', () => {目前为止，环境已经基本配置完成了
接下来就让我们开始愉快的操作系统实验之旅吧！
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 時痕！
在一切开始之前，请允许我先简要地介绍一下关于这个实验的一切
目前为止，环境已经基本配置完成了
接下来就让我们开始愉快的操作系统实验之旅吧！
本章的序将会首先介绍操作系统是如何运行起来的，并在此基础上介绍实现一个完备的操作系统实验需要实现哪些方面，以及这些部分的先后顺序和依赖关系
由于这份文档我并不打算作为一份完备的教程文档来编写，因此语言方面的介绍会相对简略或是跳过，对应的详细介绍可以参考学校的同步教程
在本章的后半部分，将会介绍MBR和中断的相关知识，记录如何编写MBR、测试使用BIOS启动MBR引导程序并通过中断输出字符串进行测试
@@ -953,7 +953,7 @@ BIOS从
0x7C00处开始执行代码，其并不区分内存中存储
下一章中，将会编写bootloader，从mbr中加载bootloader并且启动，最后在bootloader中让CPU进入保护模式在本章的第一部分中，将会介绍读取硬盘的CHS方式、LBA方式以及如何通过in、out指令读写硬盘，之后会将上一章输出Hello World!的代码移植到BootLoader中，并且从MBR中加载并跳转到编写的BootLoader执行
在第二部分中，会回顾保护模式的概念并介绍进入保护模式的四个步骤，并在开启保护模式之后输出第二个Hello World
完成
至此，就完成了本章的全部任务，赶紧使用make clean build run来测试代码的运行情况吧！
在本章节的第一部分中，将会简要介绍在下一章中将要编写的KernelLoader，以及在开始着手进行它的编写之前所需要完成的，包括各种驱动、文件系统接口等在内的诸多准备工作。
在第一部分之后，我决定按照KernelLoader中的函数调用顺序，逐节完成KernelLoader中所需要的所有准备工作，因此在第二部分中，将会首先记录如何在项目中使用C语言和汇编混合编程，包括C语言是如何进行函数调用的，以及内联汇编中NASM向AT&T迁移语法所需要注意的问题。有了这部分基础知识，就可以进行第三部分编写一些常用的驱动，并从我个人的角度讲讲为什么要这么做，它对后续的代码编写能够起到哪些帮助。
在之后的第四部分中，会进行有关文件系统的知识的详述，并且带领大家阅读微软关于FAT文件系统的文档，根据文档完成FAT文件系统接口的设计和实现。
@@ -1845,7 +1845,7 @@ VirtualPageIndex &= VirtualPageAddress >> n \nonumber \\勇者奖章
恭喜你，读完了所有日志中最长最复杂的一篇，后面的实验之路将会因这一章的努力而愈发平坦。
时隔两年，终于借着重新配置家里网络环境的契机，重新搭建了这个博客。
+时隔两年，终于借着重新配置家里网络环境的契机，重新搭建了这个博客。
原先关于操作系统的文章正在慢慢搬迁，应该很快就能恢复了~
再一次启用关于自己的博客，感觉心里良多感慨。还记得上一次搭博客时的自己，刚来到计算机学院，对着网上的保姆教程在腾讯云的小机器上搭了 git 仓库、配置了宝塔面板、DNS 解析。
那时的自己对 TLS、证书、Git、反代、CDN、Docker 这些东西都还是那么陌生，以至于教程之外的东西完全不敢去碰，哪怕是在宝塔面板上配一个 Let’s Encrypt 的证书都要折腾好久，也没有去研究 hexo deploy 到底 deploy 了什么到服务端，只觉得能跑便是好事，这也就导致了后来的删库跑路事件——本地的博客仓库被主动删除，等到发现服务器上是没有 Markdown 源文件的时候已经太迟，由于没有了源文件，写新的博客势必会导致旧的 html 被覆盖，又因为文章实在太长迟迟没有动手迁移，原先的数万字长文就这样被冻在了旧的博客里长达两年。
不夸张地说，看到熟悉的页面再一次出现在浏览器中的时候，内心有许多感慨，大概就像离家的游子多年后重新推开家门时那样吧。拂去把手上的灰尘，推开门回到曾经熟悉的地方，所有的东西都还在原本的地方等着自己，仿佛从来没有离开过那样。博客大概就是我内心无处安放的杂思的归宿吧，我想，如今它们终于又能安家了。
这一次回来，不知道能够持续多久，但我希望，能够长一些、再长一些。至于内容，我也不打算维持早年纯技术的导向了，我更多地想让这个博客成为我存在的痕迹，让多年后的自己看到曾今的文章能够会想起当年的纠结、焦虑、喜悦或是激动，能够从这里，看到我。
总之，欢迎回家。
-简单来说，方案分为了几个主要的部分：
+简单来说，方案分为了几个主要的部分：
在配博客之前，我是先配好了 Nas 上的 Gitea 服务，可以参考 在 NAS 上部署自己的 Gitea 服务，无需公网服务器 这一篇博客来准备基本的网络环境和 Gitea 服务。
(也就是说，我是先搭好了 Gitea，然后实在不知道能拿干点什么，才决定把博客迁移回来的。有点为了醋包饺子的感觉哈哈，不过现在博客全部内容都运行在自己本地感觉还是颇有成就感的)
待后面补充~
-最开始想的迁移方案是使用 skip-render 标记 html，但始终觉得不够优雅，因为导航栏、个人信息、头图之类的内容时常都会变，如果 skip-render 那永远都会是当时那个版本的页面，甚至可能超链接都是失效的，除了能显示原本的博文之外其实体验应该是相当差的——横竖感觉就是很突兀嘛！
最开始想的迁移方案是使用 skip-render 标记 html，但始终觉得不够优雅，因为导航栏、个人信息、头图之类的内容时常都会变，如果 skip-render 那永远都会是当时那个版本的页面，甚至可能超链接都是失效的，除了能显示原本的博文之外其实体验应该是相当差的——横竖感觉就是很突兀嘛！
直到今天突然意识到，hexo 渲染 markdown 为 html 文本肯定会分为三个大部分：
然后再把原先的图片复制到现在的 img 目录下，批量改一手路径，Done！
谁能想到这个卡了我两年的问题，竟然能 15 分钟就搞定了！！！
过于激动，遂特写此文记录一下，真是拍大腿啊！！！
-简单来说，方案包含了以下几个主要部分：
+简单来说，方案包含了以下几个主要部分：
不过，由于 Cloudflare 只支持有限的端口转发，并且只支持基于 http/https 协议的流量转发，因此适用面相对不那么广，但是家用部署网站服务还是绰绰有余了。具体允许的端口号见 Cloudflare 文档。
经过测试，中国联通封了 80，443，2096 端口，回源我采用的 2095 端口，这个在 Cloudflare 控制台 - 规则 - Origin Rules 可以创建回源规则针对特定域名指定。
待后续翔实~
-感觉如果博客只写长文的话，好像很快就会疲乏，其实很多时候想说的内容就是一两句话，即便硬是写成了长文，又觉得好像啰嗦了。
+感觉如果博客只写长文的话，好像很快就会疲乏，其实很多时候想说的内容就是一两句话，即便硬是写成了长文，又觉得好像啰嗦了。
看到 Hexo - Butterfly 有提供一个 “说说” 的页面可以用 .yml 格式来存一些说说文档，但是仔细一看发现好像不会自动分页，这样一来图片一多感觉加载就会变成彻底的灾难…
不知道为什么在静态编译的时候没有做成本地分页的格式呢… 就像文章那样，其实在编译阶段就可以分散到不同的 index.html 去了，好可惜，也许以后有空会想办法看看能不能改吧…
还有很多云存储的方案，但感觉把自己的内容放在云上，总感觉会比较担心数据安全和以后的迁移成本，纯本地的话哪怕一天发两条十年也不过才不到上万条数据，一个 .yml 就带走了，哎可惜没分页终究还是不打算去用。
想来想去，就把短博客也当作正常的文章一样的显示在主页吧，不过会在标题前面加上 “短文” 的标记和对应的 tag，也方便浏览的时候来做区分好了
今天收到了转正邮件，正式标志着一个新的人生阶段的开始。
+今天收到了转正邮件，正式标志着一个新的人生阶段的开始。
对自己的期望就是，不要忘记做技术的初心，在新的阶段能有所成长，有所收获。
Po 一张在鹅厂的第一个关爱里程碑~
本方案本质上是使用了安卓提供的 app_process 命令，在将 Java 代码正确地打包为需要的 .jar 或是 .dex 文件后，通过 app_process 启动对应的入口函数来实现 adb 执行 Java 代码的能力。
本方案本质上是使用了安卓提供的 app_process 命令，在将 Java 代码正确地打包为需要的 .jar 或是 .dex 文件后，通过 app_process 启动对应的入口函数来实现 adb 执行 Java 代码的能力。
对于目标 .jar 或是 .dex 文件，有两种不同的编译方案：
.dex 文件方式：思路很快确定了，就是做一个 HTTP 服务，给个 /ping 接口，客户端这边去发 GET 请求然后确认回包 200 即可。但是，问题就在于，如何能够在所有主流安卓设备上发 HTTP 请求然后判断结果呢？
最初，我想到了 curl，然后发现不是所有的设备都有 curl；于是转而投奔 nc，结果发现 nc 也不是所有的设备都有；其他的命令其实基本就也不想再试了，因为就算当前手头上的设备都能支持，谁也说不好会不会新来的机器就不支持了…
这时候都感觉仿佛只能用最最丑陋的下策了 —— 装一个 apk 包然后用 adb 拉起来然后走 socket 通信去执行 HTTP 请求。但是这样的方案，在自动化工程里面几乎是不可接受的，比如，光是自动化安装包这个环节就有各种坑可以踩，就算手动装也有不小的工作量；同时，call 起 apk 的过程也可能影响前台的 app。总之，这个方案一定是利大于弊的，因此也就没有第一时间去做尝试，而是继续去寻找可行的方案
-经过同事点拨，突然想到，平常自动化测试用到的 openatx/uiautomator 这个包，它本质上就是个 python 包装的反向代理，使得电脑端通过 python API 和手机侧的 server 通信，再把请求转换成 uiautomator 的指令加以执行。那么既然 openatx/uiautomator 是这样的 server-client 架构，那它肯定在手机上也跑了个 server 服务吧，这个服务之前有注意到就是一个 u2.jar 文件，所以应该意味着，我应该也可以写一个 Java 程序然后想办法在安卓端跑起来
经过同事点拨，突然想到，平常自动化测试用到的 openatx/uiautomator2 这个包，它本质上就是个 python 包装的反向代理，使得电脑端通过 python API 和手机侧的 server 通信，再把请求转换成 uiautomator 的指令加以执行。那么既然 openatx/uiautomator2 是这样的 server-client 架构，那它肯定在手机上也跑了个 server 服务吧，这个服务之前有注意到就是一个 u2.jar 文件，所以应该意味着，我应该也可以写一个 Java 程序然后想办法在安卓端跑起来
然后就开始了后文中试图让 Java 能在 adb shell 中跑起来的各种尝试…
最初的思路比较直接，安卓可以说是基于 Java 的，早期的运行时虚拟机 dalvikvm 即便到了 ART 时代仍然被系统所兼容，并且 dalvikvm 命令也仍然存在于所有安卓设备上，于是便试图通过 dalvikvm -cp <dex file> com.your.package.Class 来执行代码
在 demo 验证阶段，一个简单的 Hello World 程序是可以运行的，并且所有的设备都能够正确的执行，这基本证明了两点：
@@ -271,7 +272,7 @@ btf.addGlobalFn('pjaxSend', () => {atx/uiautomator2 的实现的时候，先入为主地就认为作者使用了 uiautomator <jar> 这种方式调用，后面注意力都放在了查找作者针对 u2.jar 的打包方式和相关代码上了，以至于在仓库里搜索 u2.jar 的时候竟然没有注意到在搜索结果中 core.py 赫然有着 command = "CLASSPATH=/data/local/tmp/u2.jar app_process / com.wetest.uia2.Main" 这一启动方式，与答案擦肩而过并且进一步在寻找 uiautomator 1.0 的打包方式上浪费了大半天的时间快要到年底绩效考核的时间了，回想过去半年好像一直忙忙碌碌但好像又没有什么很亮眼的成果。期间还有一大部分精力都投在了一个设计难度远大于实现难度的需求。
+快要到年底绩效考核的时间了，回想过去半年好像一直忙忙碌碌但好像又没有什么很亮眼的成果。期间还有一大部分精力都投在了一个设计难度远大于实现难度的需求。
回过头想想，其实在工作上开始做一件长期的事情之前，还是要去评估可行性、投入以及收效，到底这件事情有多大的优先级，是不是就值得现在立马开始投入人力去做这个。到底做些什么可以被业务感知到，从而去判断，到底哪些需求才是重要的，而不是一味的承接需求，最后反倒抓不到重点了。
当然，除此之外，更重要的一点是，在知道了公司存在强制的 Underperform 比例时，不免会想，也许有一天我也要成为背这个绩效的人？在这种场景下，是否不要把鸡蛋放在一个篮子里更为安全？诚然，上班本质还是一种利益交换，我给公司提供我能够产出的内容，帮助公司节省人力开支或是做原本人力做不了的事情，公司给我反馈大厂背景、经验、人脉和钱，当然，这里面必然伴随着剩余价值的剥削云云，但总的来看，也算是目前相对公平且不错的买卖，在这样的背景下，我还是会在工作的时候专注于需求本身，坚守住技术人应有的底线，但在工作时间之外，确实应该更加关注自身的投资，也许是身体的健康，也许是产品思维，也许真的去做一些能代表自己实力的东西吧。
前几天有看到一个帖子，个人认为说的其实很有道理，大致意思就是，人总要有一些能证明自己能力的东西，在校招的时候，学历就是最大的背书；在工作的时候，便是绩效和公司、项目经历。但是，如果能有足够的其他履历，比如大的开源项目、成功的产品，这些就会替代前者变成能力的证明，毕竟，选择前者只是没有后者的无奈之举。所以，我想，做自己感兴趣的事，并且在这方面出彩，大概才是最有价值的投资吧。
-