操统实验日志 第一章 序章
简述
+操统实验日志 第一章 序章
简述
在一切开始之前，请允许我先简要地介绍一下关于这个实验的一切
它是关于什么的
@@ -506,7 +506,7 @@ btf.addGlobalFn('pjaxSend', () => {目前为止，环境已经基本配置完成了
接下来就让我们开始愉快的操作系统实验之旅吧！
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 時痕！
在一切开始之前，请允许我先简要地介绍一下关于这个实验的一切
目前为止，环境已经基本配置完成了
接下来就让我们开始愉快的操作系统实验之旅吧！
本章的序将会首先介绍操作系统是如何运行起来的，并在此基础上介绍实现一个完备的操作系统实验需要实现哪些方面，以及这些部分的先后顺序和依赖关系
由于这份文档我并不打算作为一份完备的教程文档来编写，因此语言方面的介绍会相对简略或是跳过，对应的详细介绍可以参考学校的同步教程
在本章的后半部分，将会介绍MBR和中断的相关知识，记录如何编写MBR、测试使用BIOS启动MBR引导程序并通过中断输出字符串进行测试
diff --git a/2022/07/19/os-journal-vol-3/index.html b/2022/07/19/os-journal-vol-3/index.html index 2f050f4..2dcfa83 100644 --- a/2022/07/19/os-journal-vol-3/index.html +++ b/2022/07/19/os-journal-vol-3/index.html @@ -7,7 +7,7 @@ - + @@ -166,7 +166,7 @@ isHome: false, isHighlightShrink: false, isToc: true, - postUpdate: '2024-11-22 16:49:44' + postUpdate: '2024-11-22 16:52:44' }在本章的第一部分中，将会介绍读取硬盘的CHS方式、LBA方式以及如何通过in、out指令读写硬盘，之后会将上一章输出Hello World!的代码移植到BootLoader中，并且从MBR中加载并跳转到编写的BootLoader执行
在第二部分中，会回顾保护模式的概念并介绍进入保护模式的四个步骤，并在开启保护模式之后输出第二个Hello World
在本章节的第一部分中，将会简要介绍在下一章中将要编写的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 被覆盖，又因为文章实在太长迟迟没有动手迁移，原先的数万字长文就这样被冻在了旧的博客里长达两年。
简单来说，方案分为了几个主要的部分：
+简单来说，方案分为了几个主要的部分：
最开始想的迁移方案是使用 skip-render 标记 html，但始终觉得不够优雅，因为导航栏、个人信息、头图之类的内容时常都会变，如果 skip-render 那永远都会是当时那个版本的页面，甚至可能超链接都是失效的，除了能显示原本的博文之外其实体验应该是相当差的——横竖感觉就是很突兀嘛！
最开始想的迁移方案是使用 skip-render 标记 html，但始终觉得不够优雅，因为导航栏、个人信息、头图之类的内容时常都会变，如果 skip-render 那永远都会是当时那个版本的页面，甚至可能超链接都是失效的，除了能显示原本的博文之外其实体验应该是相当差的——横竖感觉就是很突兀嘛！
直到今天突然意识到，hexo 渲染 markdown 为 html 文本肯定会分为三个大部分：
简单来说，方案包含了以下几个主要部分：
+简单来说，方案包含了以下几个主要部分：
感觉如果博客只写长文的话，好像很快就会疲乏，其实很多时候想说的内容就是一两句话，即便硬是写成了长文，又觉得好像啰嗦了。
+感觉如果博客只写长文的话，好像很快就会疲乏，其实很多时候想说的内容就是一两句话，即便硬是写成了长文，又觉得好像啰嗦了。
看到 Hexo - Butterfly 有提供一个 “说说” 的页面可以用 .yml 格式来存一些说说文档，但是仔细一看发现好像不会自动分页，这样一来图片一多感觉加载就会变成彻底的灾难…
不知道为什么在静态编译的时候没有做成本地分页的格式呢… 就像文章那样，其实在编译阶段就可以分散到不同的 index.html 去了，好可惜，也许以后有空会想办法看看能不能改吧…
还有很多云存储的方案，但感觉把自己的内容放在云上，总感觉会比较担心数据安全和以后的迁移成本，纯本地的话哪怕一天发两条十年也不过才不到上万条数据，一个 .yml 就带走了，哎可惜没分页终究还是不打算去用。
今天收到了转正邮件，正式标志着一个新的人生阶段的开始。
+今天收到了转正邮件，正式标志着一个新的人生阶段的开始。
对自己的期望就是，不要忘记做技术的初心，在新的阶段能有所成长，有所收获。
Po 一张在鹅厂的第一个关爱里程碑~
本方案本质上是使用了安卓提供的 app_process 命令，在将 Java 代码正确地打包为需要的 .jar 或是 .dex 文件后，通过 app_process 启动对应的入口函数来实现 adb 执行 Java 代码的能力。
本方案本质上是使用了安卓提供的 app_process 命令，在将 Java 代码正确地打包为需要的 .jar 或是 .dex 文件后，通过 app_process 启动对应的入口函数来实现 adb 执行 Java 代码的能力。
对于目标 .jar 或是 .dex 文件，有两种不同的编译方案：
.dex 文件方式：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 比例时，不免会想，也许有一天我也要成为背这个绩效的人？在这种场景下，是否不要把鸡蛋放在一个篮子里更为安全？诚然，上班本质还是一种利益交换，我给公司提供我能够产出的内容，帮助公司节省人力开支或是做原本人力做不了的事情，公司给我反馈大厂背景、经验、人脉和钱，当然，这里面必然伴随着剩余价值的剥削云云，但总的来看，也算是目前相对公平且不错的买卖，在这样的背景下，我还是会在工作的时候专注于需求本身，坚守住技术人应有的底线，但在工作时间之外，确实应该更加关注自身的投资，也许是身体的健康，也许是产品思维，也许真的去做一些能代表自己实力的东西吧。
前几天有看到一个帖子，个人认为说的其实很有道理，大致意思就是，人总要有一些能证明自己能力的东西，在校招的时候，学历就是最大的背书；在工作的时候，便是绩效和公司、项目经历。但是，如果能有足够的其他履历，比如大的开源项目、成功的产品，这些就会替代前者变成能力的证明，毕竟，选择前者只是没有后者的无奈之举。所以，我想，做自己感兴趣的事，并且在这方面出彩，大概才是最有价值的投资吧。
-先挖坑，慢慢填
+日常工作中，经常会需要临时 Clone 某个仓库并且用 VSCode 打开，在 Windows 上我一般都是：
+日常工作中，经常会需要临时 Clone 某个仓库并且用 VSCode 打开，在 Windows 上我一般都是：
git clone某天在 Windows 宿主机上执行任务时，发现 wda 指令请求一直失败，查看日志发现唯一有效的错误日志是 Only one usage of each socket address (protocol/network address/port) is normally permitted，回顾宿主机环境在过去一段时间没有进行过变更，并且该问题是第一次出现，此前相同环境并没有出现过这个问题
某天在 Windows 宿主机上执行任务时，发现 wda 指令请求一直失败，查看日志发现唯一有效的错误日志是 Only one usage of each socket address (protocol/network address/port) is normally permitted，回顾宿主机环境在过去一段时间没有进行过变更，并且该问题是第一次出现，此前相同环境并没有出现过这个问题
尝试在其他宿主机以及本地开发机上执行相同命令均不能稳定复现该问题，其中 Linux 开发机无法复现该问题
由于报错信息只有一行，也只能从这个信息来入手。搜索引擎检索得到如下内容：
listen 同一端口引起，阅读提问者提供的代码确实有此问题由于此前宿主机并没有暴露出该问题，优先考虑并不是发起请求及接收请求的 client 及 wda 侧的问题，即第一篇文章中提到的可能，而是从宿主机上的 tcp 连接状况入手来进一步分析这个问题，于是主要的关注点转向如下方面：