[RFC]: 启动架构重构 | Launch process refactoring

[chiichen]

简介 | Brief Introduction

现有的启动流程中，无法便捷的进行系统的自定义，比如在未来可能引入的测试框架中，选择是否开启某些测试、选择默认加载哪些用户程序、选择启动模式、是否开启gdb等等。现在这些都是要通过一些手动配置，或者通过make参数指定。这里我希望可以通过一种结构化的配置文件(toml会是一个不错的选择，后文会描述优点)，来完整描述系统的启动行为

想法 | Ideas

以下是目前设想的一套启动流程，欢迎大家在issue下讨论，基本想法是，把现有的dadk从一个用户程序加载工具，变成启动配置加载+启动命令生成+用户程序加载+测试套件(可选)，把现有的make run系列命令，迁移为cargo dadk run

工作 | Jobs

1. 将现有dadk改写为cargo插件的形式便于集成
2. 将现有dadk 用户程序配置从json迁移为toml配置(可选)
3. 在dadk中集成启动模块，可以用dadk作为入口进入，简单理解就是把启动流程中的 make 命令替换成 cargo dadk 命令
4. 实现内核配置项，支持dadk读取配置，并以配置启动
5. dadk集成测试套件(需要另外探讨)

为什么用 toml | Why toml

最重要的一点是，toml可以很便捷地扩展出代码提示和高亮功能，vscode 上的 even better toml插件支持从自定义的json schema对toml配置进行解析，他就是这样实现对Cargo.toml的代码提示的。另一个就是更可读的语义。

[fslongjin]

感觉内核配置跟应用程序编译的配置是不是要进行一定解耦？

[chiichen]

感觉内核配置跟应用程序编译的配置是不是要进行一定解耦？

我觉得是这样的，其实现在应用程序可以被分成两部分，一个是系统预装的软件，例如core utils，还有一些就是用来测试的，例如test_xxx，前者我觉得应该也属于系统配置的一部分，我这里的系统配置指的是内核启动配置(比如启动模式，启动架构等等)+预装软件(core utils/busybox)，后者我觉得就应该是要被划分到测试那一块了

预装软件这个我觉得就有点像系统镜像，就是用户可以打包一些软件到最后的系统里