false positive: arceos#mingo 针对特定架构进行编译

[zjp-CN]

代码之一：

#[cfg(target_arch = "aarch64")]
#[path = "_arch/aarch64/cpu.rs"]
mod arch_cpu;

error[E0432]: unresolved import `arch_cpu`
  --> src/cpu.rs:16:9
   |
16 | pub use arch_cpu::{nop, wait_forever};
   |         ^^^^^^^^ use of undeclared crate or module `arch_cpu`

# Platform specific dependencies
[target.'cfg(target_arch = "aarch64")'.dependencies]
aarch64-cpu = { version = "9.x.x" }

[zjp-CN]

解决这个问题有些棘手，我的想法是把现有的数据从 os-checker/os-checker.github.io 仓库中分离到单独的数据仓库，然后在那个数据仓库按照 user/repo/packages 组织结构存放 JSON。但细节远不止于此：

目前有或者计划几个正交维度的 JSON 数据：总计、原始输出、时间、架构等维度，那么似乎目录结构应该变成 user/repo/packages/package1/{datetime,latest}/raw-reports.json， 其中 latest 作为最后一次更新的结果，不仅有利于 UI 获取数据，也有利于比较是否需要更新；至于总计，我们可以不再通过 os-checker CLI 计算，而是基于这个原始输出计算到 user/repo/analysis/{datetime,latest}/total_counts.json。

需要这样分离数据，是因为有些仓库包含的 packages 需要不同架构平台才能编译或者分析（我们还没有考虑过同一个 package 在不同平台编译或者分析的情况！），那么这显然意味着需要在 A 架构上检查这个仓库的一部分代码（并排除另一部分代码），然后在 B 架构上检查另一部分代码等等 —— 也就是说，即使对于原始输出，数据也是部分生成最终才合并的。如果需要考虑多平台编译，那么这个原始输出目录结构需要变成 user/repo/arch-A/packages/package1/{datetime,latest}/raw-reports.json （或者依然保持不含架构的目录 user/repo/packages/package1/{datetime,latest}/raw-reports.json，把架构信息加到 raw-reports.json 文件名或者 JSON 内容里？）。

嗯... 事情变得越来越复杂。我们还可能遇到目前尚未想到或者尚未计划，但将来需要拓展的维度，比如对同一个仓库的不同分支进行检查... 那么原始输出目录结构需要变成 user/repo/branch1/arch-A/packages/package1/{datetime,latest}/raw-reports.json 。

总之，这越来越难管理，需要数据库来存储原始数据/输出，然后生成这些目录结构：比如（关系型）数据库适合将这些正交维度记录到二维表，方便统一分析/汇总和进一步处理；至于目录结构，我们可以轻易从数据库中生成它们。

为什么我们依然还需要目录结构：因为 os-checker.github.io 是静态网页部署，在无服务器的情况下，所有数据必须提前生成好，以便容易直接获取 —— 在前端直接使用数据库是不寻常的事情。。。

[zjp-CN]

在 github action 中支持多架构编译，需要 qemu 模拟器，一些参考资料：

• Github actions runner environment doesn't build for arm images
• docker/setup-qemu-action
  • https://github.com/docker/setup-qemu-action
  • https://docs.docker.com/build/ci/github-actions/multi-platform/
  • https://www.agas.dev/github-actions-docker-build

[zjp-CN]

对于 mingo (代码位于 tools/raspi4/chainloader 目录），实际上，OP 中的错误是 Rust 条件编译错误引发的，而静态检查虽然依然需要编译成功，但不需要链接成功（即并不需要构建），因此我们暂时不需要配备多架构环境，而是在现有的 x86-64 上增加一个编译目标 （rustup target add aarch64-unknown-none），即

tools/raspi4/chainloader $ cargo clippy/check --target aarch64-unknown-none -F bsp_rpi3
   Compiling mingo v0.6.0 (/rust/my/os-checker/repos/arceos/tools/raspi4/chainloader)
warning: methods `chars_written` and `chars_read` are never used
  --> src/console.rs:45:12
   |
43 |     pub trait Statistics {
   |               ---------- methods in this trait
44 |         /// Return the number of characters written.
45 |         fn chars_written(&self) -> usize {
   |            ^^^^^^^^^^^^^
...
50 |         fn chars_read(&self) -> usize {                                                                                                                                                       |            ^^^^^^^^^^
   |
   = note: `#[warn(dead_code)]` on by default                                                                                                                                                   
warning: `mingo` (bin "kernel") generated 1 warning
    Finished `dev` profile [unoptimized + debuginfo] target(s)

如果进行构建（我们实际不需要构建），则失败：

tools/raspi4/chainloader $ cargo b --target aarch64-unknown-none -F bsp_rpi3
...
error: linking with `rust-lld` failed: exit status: 1
...

P.S. 这里不仅涉及架构目标 --target aarch64-unknown-none，还涉及 feature flags -F bsp_rpi3。