my_report_3

source/_posts/OS项目-igb驱动开发总结.md

@@ -0,0 +1,43 @@
+---
+title: OS项目unikernel igb驱动开发总结
+date: 2024-12-20 20:25:37
+tags: 
+  - author:<ghostdragonzero>
+  - repo:<https://github.com/ghostdragonzero/arceos_test>
+---
+
+# 一、验证说明
+在这个仓库中 https://github.com/ghostdragonzero/arceos_test 我直接修改了ixgbe的pid vid匹配参数来匹配igb网卡，并且通过修改axdriver到引用我自己的仓库。以此来实现替换ixgbe的目的。
+拉取后可以直接执行`make A=examples/httpserver PLATFORM=aarch64-qemu-virt LOG=debug SMP=2 NET=y FEATURES=driver-ixgbe NET_DEV=user run`
+
+这个仓库 https://github.com/ghostdragonzero/igb-driver/tree/my_driver 
+是我在share_test框架下实现的驱动完成了 link_up rx_init tx_init 初始化流程也是我在这个框架下实现然后搬到ixgbe框架里在arceos内运行没问题的
+但是这里实现的memry是使用的arceos中hal的实现   ring结构是直接使用的ixgbe的ring
+
+
+
+# 二、学习的感受
+这是我第一次成功完成这个训练营，之前参加了很多次都在各种阶段就没有坚持下去，这次能成功完成是相当开心的。
+
+并且这次的驱动开发给我感受最深的就是，**硬件（虽然是模拟的外设）的逻辑是很固定的出现了预期之外的行为，99%是自己写的存在错误**
+记录我认为在我开发的时候我查看时间最久的问题：
+1. 注意有效数据位
+在操作MDIC寄存器的时候，我使用的先读取在写入的方法，但是我读取的是u32，它的数据位是低16位。我把高位的标志位也保留到了下次要写的数据里面。导致一直出错，后面是使用断点调试的方法才对比出来不同再进行了改正。
+2. 注意不要定义类似的常量
+还是在操作MCIC寄存器的时候  在判断标志位时候我错误的使用了**MDIC_READ**作为**READY**导致我一直读取成功但是写失败，这我反复的追查了好久，但是这也是我自己的不细心。
+3. 注意set_flag和set_reg的区别
+这是在最后的检查的时候发现的，因为是在ixgbe的基础上使用的所以一些寄存器不仅仅是地址变了  一些功能也分配到了不同的寄存器，而导致有些适用set_reg有些则应该是set_flag
+这一点要尤其注意因为很多时候就是一些标志位的不同就会有不一样的地方
+
+
+# 三、学习的总结
+这次学习给我最大的收获就是真的从datasheet来一步步的开发一个驱动的经验，并且在开发的过程中一步一步的调试，通过设置断点来看寄存器的值。这个是我最喜欢的一个功能，因为我在平时驱动的开发时候最难受的就是修改需要编译版本才能做验证，找不到一个快速验证的办法导致问题进展缓慢。如果能有多一点的可以这样来验证的控制就好了。
+
+再来说一下，这次学习中我的不足，实际上我算是让这个网卡能用起来了 但是我还是不理解他更上层的东西，不清楚他的ring是怎样收发信息的，不明白他这个网络是怎么跑通的，群友说的报文又是什么。体现在开发过程中就是，出现问题我只能再次去查看linux的igb驱动都配置了哪些寄存器，ixgbe有什么流程但是对于这些流程的意义我不明白，只是datasheet上写了，或者看到其他驱动做了于是我也就去做试试看。
+
+感觉还需要继续学习一下网络相关的基本概念才能真的完成这个网卡驱动
+
+# 四、关于ixgbe与igb的思考
+因为我是直接鸠占鹊巢的方式在arceos里成功用起来igb，所以我认为既然能够这样用起来 是不是侧面说明对于ixgb_hal和ixgbe_nic的抽象就是一个能够在igb上（或者同一E100系列的网卡）复用的结构。后续是不是可以直接通过条件编译或者直接在网卡驱动的匹配处来区分出来，这样可以减少重复的代码结构，并且我认为上层本来也不关心下层实际的控制器。
+
+

source/_posts/第三阶段总结-ghost.md

@@ -0,0 +1,52 @@
+---
+title: <第三阶段总结-ghost>
+date: 2024-12-01 19:38:07
+tags:
+    - author:<ghostdragonzero>
+---
+
+# 一、前言
+这个月因为一些工作的原因并没有很好的完成课程的学习挑战这些内容，对于课程只看完了宏内核部分。但是我认为我学到了我感兴趣的部分。对于这部分我学习的感受就是是对于之前的os开发的进一步学习，对于unikernel的组件就是之前rustos实现的部分的更加具体的模块化。（虽然我还是在涉及内存以及地址的部分有些不明白）
+
+# 二、 unikernel
+
+## 对比裸机和RTOS
+对比裸机  这样的组件化操作系统可以更快的添加功能  适配硬件
+对比RTOS 可以更加灵活的做删减 比如替换使用的调度算法
+更像是一种进化的裸机  所有操作系统都是为了应用而存在的
+为应用的功能拆解出各种需要的模块  再拼装成一个只为了这个应用而存在的系统
+
+## 系统有关与系统无关模块
+所有的使用的模块都算作是系统无关的  
+只有你使用这些系统无关的模块所构成的就是一个系统有关的系统
+说到底就是可替换和不可替换的  
+对于一些模块的功能是不可替换的 就可以说是系统相关的
+而对于一部分模块来说就是 可有可无根据需要的特性去选择的就是系统无关的
+
+## 我的理解
+感觉就像是发展又发展了回去 一开始都是专业的产品 后面开始做通用性的产品当达到一定程度后又开始专业化
+## 进一步思考
+那就说明这个是一个高度定制化的系统 
+目的应该就是在性能更低的平台 来实现更为定制的功能
+所以我理解就是  一个定制产品 而不是一个需要很多额外性能  来在一个通用计算机上实现的产品
+那么我认为 这个系统应该要和芯片相绑定的 甚至这个应该更为适合fpga平台
+来实现真正意义上的软硬一体  
+一个从一开始就是为了通用计算设计制造的芯片
+我觉得会成为这样定制性系统的瓶颈  如果发展下去
+
+# 宏内核
+相对于unikernl 宏内核增加了一个用户特权级
+这样不同的特权级  让应用更加安全因为不能直接访问到内核内的
+
+多伪造了一个所谓的应用态 调用了一次sret来让系统从特权态进入到用户态
+我认为这样扩展出来的宏内核系统  就像是在嵌入式设备中常见的中枢网关  
+## 我的理解
+这样扩展ArcOS的内核类型我觉得就像是课里面老师说的对于设备端使用unikernel 对于管理端使用宏内核
+我感觉这是在构建一个分布式的场景
+
+
+unikernel的异构思想  就是将共同的组件作为基础
+而将不同内核最大的特性作为独立的组件  这样就类似存在多种内核的系统
+通过多种异构的内核 但是其中又使用了共同的模块又能有一定的统一性  
+或者说后期的维护 可以由一个团队共同维护一个场景 
+可以避免互相不清楚对方的模块导致无法定位问题所在的地方