讨论:如何自定义系统的安装配置

起因

目前我们都是在user/dadk目录下放置用户程序的配置文件的。这导致了几个问题:

  1. 用户程序每更新一个版本,都需要提交一个新的commit到主仓库(尽管可以选择分支而不是revision,但是这样就导致发新版本的时候,还需要人工操作,固定revision)
  2. 没法很方便的配置“到底应该安装哪些用户程序到系统内”。

想法

因此我个人想法是,可以参照linux buildroot项目,我们也搞一个类似的,用于构建出完整可运行的DragonOS. 通过Kconfig的图形界面来配置安装选项。然后编写脚本,并与dadk相结合,从而实现个性化安装。

作用

除了上述的“个性化安装”以外,感觉这个项目还可以有别的用途:

  • 方便进行自动化回归测试、集成测试:可以很方便的把测试程序的配置放进来,由CI/CD的系统每天晚上跑nightly的回归测试。
  • 项目发布nightly版本,用户可以自由下载最新版的dragonos的镜像来体验
  • 甚至方便我们做“系统安装镜像”之类的东西。

总之就是提升DragonOS构建的可配置程度。

问题

但是,这个感觉会有问题:

  • 如何设计构建缓存的策略,毕竟全部重编需要很久,但是如果改了编译配置,那么又要让一些缓存失效,否则会导致奇奇怪怪的问题

讨论

欢迎大家在本帖下,一起讨论,提出自己的疑惑和建议,最终形成一套完整的方案。

linux buildroot项目大概是,他把各种软件包的编译命令脚本、镜像源都给预先设置好了,然后通过Kconfig去配置,最终一键编译。
然后生成一个镜像,以及一个start-qemu.sh脚本。直接执行脚本就能运行系统。

我也觉得需要搞配置
很多时候不需要安装全部的用户程序
并且随着测试程序的增多,把用户程序代码和kernel放在一起显得很混乱,也不好操作(比如直接在DragonOS项目里编写用户程序,没有代码提示)

我认为可以把用户程序独立到一个个小项目中,这些小项目由个人来管理,而不是集中在组织的名下,但这需要修改git镜像的配置,添加这些小仓库的镜像,并确保在进行一些危险操作(比如force push)时由管理员审核。或者使用gitea或类似的项目来搭建一个远程git仓库,并把这些小仓库放到这里

我目前的考量点有3个:

  • 下载慢、github无法访问的问题:直接克隆代码。国内大概率无法访问github.那么克隆会成问题。
  • 可持续构建的问题:如果不是放在社区仓库下,那么就可能由于有的作者删库/改名导致无法正确构建系统。
  • 安全性问题:这是最重要的。将来我们会在(其实目前也有一些在跑了)内网的CI/CD系统上面跑自动化测试、自动构建之类的操作。如果仓库不在DragonOS组织下,我担心引入恶意程序/错误的脚本,对内网造成安全隐患。当然这个也许可以通过签署CLA来解决,由仓库提供者签署CLA,以向社区保证该仓库不会出现恶意代码之类的。(那就意味着如果仓库内的脚本会出现攻击行为,社区会向该开发者追究法律责任)