创建仓库
This commit is contained in:
120
系统基座文件/1/1.1/1.1.1 发行版与内核版本指纹.md
Normal file
120
系统基座文件/1/1.1/1.1.1 发行版与内核版本指纹.md
Normal file
@@ -0,0 +1,120 @@
|
||||
---
|
||||
tags: []
|
||||
date created: 星期三, 十一月 19日 2025, 3:10:38 下午
|
||||
date modified: 星期三, 十一月 19日 2025, 5:42:25 下午
|
||||
---
|
||||
|
||||
# 1.1.1 发行版与内核版本指纹
|
||||
|
||||
**1. OS 发行版完整标识 (Distro Full ID)**
|
||||
|
||||
- **关键性**：P0
|
||||
- **预期信息**：确认具体的 SP 版本（如 V10 SP1/SP2/SP3），不同版本的 Glibc 和内核基线差异极大。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
cat /etc/kylin-release /etc/os-release 2>/dev/null | grep -E "PRETTY_NAME|VERSION_ID|Kylin Linux Advanced Server"
|
||||
Kylin Linux Advanced Server release V10 (GFB)
|
||||
NAME="Kylin Linux Advanced Server"
|
||||
VERSION_ID="V10"
|
||||
PRETTY_NAME="Kylin Linux Advanced Server V10 (GFB)"
|
||||
```
|
||||
|
||||
**2. CPU 架构与字节序 (Arch & Endianness)**
|
||||
|
||||
- **关键性**：P0
|
||||
- **预期信息**：必须确认为 aarch64 且为 Little Endian（小端序），这是 Feiteng S5000C 的基础特征。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
lscpu | grep -E "Architecture|Byte Order"
|
||||
空
|
||||
```
|
||||
|
||||
**3. 内核发布版本号 (Kernel Release)**
|
||||
|
||||
- **关键性**：P0
|
||||
- **预期信息**：精确的内核版本字符串。驱动源码的 Header Path 必须与此完全一致。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
uname -r
|
||||
4.19.90-52.23.v2207.gfb08.ky10.aarch64
|
||||
```
|
||||
|
||||
**4. 内核构建编译器版本 (Kernel GCC Version)**
|
||||
|
||||
- **关键性**：P0
|
||||
- **预期信息**：提取圆括号内的 gcc version。如果此版本与当前环境中 gcc 版本差异过大，编译内核模块时极易报错。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
cat /proc/version
|
||||
Linux version 4.19.90-52.23.v2207.gfb08.ky10.aarch64 (KYLINSOFT@localhost.localdomain) (gcc version 7.3.0 (GCC)) #1 SMP Tue Apr 23 18:20:01 CST 2024
|
||||
```
|
||||
|
||||
**5. 内核启动参数全集 (Kernel Boot Cmdline)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **预期信息**：检查是否已有预设的 isolcpus、hugepages 或 iommu 参数，判断基线是否纯净。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
cat /proc/cmdline
|
||||
BOOT_IMAGE=/vmlinuz-4.19.90-52.23.v2207.gfb08.ky10.aarch64 root=/dev/mapper/klas-root ro rd.lvm.lv=klas/root rd.lvm.lv=klas/swap acpi=on rhgb quiet console=tty0 crashkernel=1024M,high smmu.bypassdev=0x1000:0x17 smmu.bypassdev=0x1000:0x15 video=efifb:off module_blacklist=phytium_mci_pci module_blacklist=phytium_mci audit=0
|
||||
```
|
||||
|
||||
**6. 内核构建时间戳 (Kernel Build Timestamp)**
|
||||
|
||||
- **关键性**：P2
|
||||
- **预期信息**：确认内核是原厂构建还是用户自行重新编译过的版本。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
uname -v
|
||||
#1 SMP Tue Apr 23 18:20:01 CST 2024
|
||||
```
|
||||
|
||||
**7. 内核模块签名强制性 (Module Signing Policy)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **预期信息**：检查 CONFIG_MODULE_SIG_FORCE。如果是 y，则加载未签名的自研驱动会被拒绝。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
grep "CONFIG_MODULE_SIG" /boot/config-$(uname -r) 2>/dev/null || echo "Config check failed"
|
||||
CONFIG_MODULE_SIG=y
|
||||
# CONFIG_MODULE_SIG_FORCE Is not Set
|
||||
CONFIG_MODULE_SIG_ALL=y
|
||||
# CONFIG_MODULE_SIG_SHA1 is not set
|
||||
# CONFIG_MODULE_SIG_SHA224 is not set
|
||||
CONFIG_MODULE_SIG_SHA256=y
|
||||
# CONFIG_MODULE_SIG_SHA384 is not set
|
||||
# CONFIG_MODULE_SIG_SHA512 is not set
|
||||
CONFIG_MODULE_SIG_HASH="sha256"
|
||||
CONFIG_MODULE_SIG_KEY="certs/signing_key.pem"
|
||||
```
|
||||
|
||||
**8. 安全模块状态 (LSM Status)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **预期信息**：确认 SELinux 或 Kysec（麒麟安全子系统）的状态，这是导致设备节点无权限访问的常见原因。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
sestatus 2>/dev/null; getenforce 2>/dev/null; ls -d /sys/kernel/security/lsm
|
||||
SELinux status: disabled
|
||||
Disabled
|
||||
/sys/kernel/security/lsm
|
||||
```
|
||||
|
||||
**9. 页大小配置 (Page Size Configuration)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **预期信息**：aarch64 架构下可能存在 4KB 或 64KB 页大小的差异。页大小不匹配会导致内存映射（mmap）失败。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
getconf PAGESIZE
|
||||
65536
|
||||
```
|
||||
77
系统基座文件/1/1.1/1.1.2 内存子系统策略 (Memory Subsystem Policy).md
Normal file
77
系统基座文件/1/1.1/1.1.2 内存子系统策略 (Memory Subsystem Policy).md
Normal file
@@ -0,0 +1,77 @@
|
||||
---
|
||||
tags:
|
||||
aliases:
|
||||
- 1.1.2 内存子系统策略 (Memory Subsystem Policy)
|
||||
date created: 星期三, 十一月 19日 2025, 3:48:55 下午
|
||||
date modified: 星期三, 十一月 19日 2025, 3:49:00 下午
|
||||
---
|
||||
|
||||
# 1.1.2 内存子系统策略 (Memory Subsystem Policy)
|
||||
|
||||
**1. 透明大页状态 (Transparent HugePages Status)**
|
||||
|
||||
- **关键性**：P0
|
||||
- **预期信息**：查看当前状态是 `[always]` 还是 `[never]`。在 64KB 基础页宽的系统上，THP 机制更为激进，极易导致内存碎片化和不可预测的内核态 CPU 占用（sys cpu high）。雷达实时处理业务通常强制要求设为 `never` 或 `madvise`。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
cat /sys/kernel/mm/transparent_hugepage/enabled
|
||||
always [madvise] never
|
||||
```
|
||||
|
||||
**2. 标准大页尺寸 (Default Hugepage Size)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **预期信息**：确认系统默认的大页物理尺寸。在 x86 (4KB 页) 上通常是 2MB；但在 64KB 页宽的 aarch64 系统上，一级大页通常是 **512MB**。这直接决定了驱动程序（如 DMA 缓冲）申请连续物理内存时的对齐粒度和最小单元。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
grep "Hugepagesize" /proc/meminfo
|
||||
Hugepagesize: 524288 kB
|
||||
```
|
||||
|
||||
**3. 大页内存预留量 (Total HugePages)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **预期信息**：检查系统是否在启动阶段通过 Boot Args 预留了物理大页。若显示 `0`，说明完全依赖运行时分配。对于从 ADC 采集的高速数据流，运行时动态申请大页极易失败，必须确认是否有静态预留。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
grep "HugePages_Total" /proc/meminfo
|
||||
HugePages_Total: 0
|
||||
```
|
||||
|
||||
**4. 虚拟内存交换倾向 (Swappiness)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **预期信息**：数值范围 0-100。对于实时雷达系统，任何形式的 Swap-out（内存换出）都是致命的，会导致毫秒级的处理中断。该值应被严格限制在 `0` 或 `10` 以内。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
cat /proc/sys/vm/swappiness
|
||||
10
|
||||
```
|
||||
|
||||
**5. 内存过载分配策略 (Overcommit Memory Policy)**
|
||||
|
||||
- **关键性**：P2
|
||||
- **预期信息**：返回值为 `0` (启发式), `1` (总是允许), 或 `2` (严格限制)。GPGPU 驱动初始化时常需预分配巨大的虚拟地址空间，若此值为 `2` (禁止过载) 且无足够 Swap，驱动初始化（`cudaMalloc` 等价调用）可能会直接崩溃。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
cat /proc/sys/vm/overcommit_memory
|
||||
0
|
||||
```
|
||||
|
||||
**6. 物理内存全景 (Physical Memory Overview)**
|
||||
|
||||
- **关键性**：P2
|
||||
- **预期信息**：获取 `Total`（物理总内存）与 `Available`（实际可用）。需特别关注在 64KB 页系统下，内核自身的数据结构（Page Tables）会消耗比 x86 更多的内存，需评估剩余内存是否满足信号处理算法的峰值需求。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
free -h
|
||||
total used free shared buff/cache available
|
||||
Mem: 62Gi 2.8Gi 58Gi 81Mi 1.2Gi 54Gi
|
||||
Swap: 8.0Gi 0B 8.0Gi
|
||||
```
|
||||
115
系统基座文件/1/1.1/1.1.3 CPU 调度与核心隔离 (CPU Scheduling & Isolation).md
Normal file
115
系统基座文件/1/1.1/1.1.3 CPU 调度与核心隔离 (CPU Scheduling & Isolation).md
Normal file
@@ -0,0 +1,115 @@
|
||||
---
|
||||
tags:
|
||||
date created: 星期三, 十一月 19日 2025, 3:56:35 下午
|
||||
date modified: 星期三, 十一月 19日 2025, 3:56:46 下午
|
||||
---
|
||||
|
||||
# 1.1.3 CPU 调度与核心隔离 (CPU Scheduling & Isolation)
|
||||
|
||||
**1. CPU 物理拓扑与 NUMA 布局 (CPU Topology & NUMA Layout)**
|
||||
|
||||
- **关键性**：P0
|
||||
- **预期信息**：确认物理核心数、Socket 数量及 NUMA 节点分布。Feiteng S5000C 通常为多路多核架构，跨 NUMA 节点的内存访问会导致显著的时延抖动，需确认 CPU 核心与 NUMA 节点的亲和性映射。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
lscpu -e=CPU,NODE,SOCKET,CORE,CACHE
|
||||
CPU NODE SOCKET CORE L1d:L1i:L2:L3
|
||||
0 0 0 0 0:0:0:0
|
||||
1 0 0 1 1:1:1:0
|
||||
2 0 0 2 2:2:2:0
|
||||
…
|
||||
15 0 0 15 15:15:15:0
|
||||
16 1 0 16 16:16:16:1
|
||||
17 1 0 17 17:17:17:1
|
||||
…
|
||||
31 1 0 31 31:31:31:1
|
||||
```
|
||||
|
||||
**2. 运行时核心隔离状态 (Runtime CPU Isolation)**
|
||||
|
||||
- **关键性**：P0
|
||||
- **预期信息**：检查内核是否已成功隔离指定核心（返回核心列表）。被隔离的核心将不再接收操作系统的常规任务调度，仅处理绑定到该核心的实时雷达信号处理线程。若为空，说明未配置隔离。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
cat /sys/devices/system/cpu/isolated
|
||||
|
||||
```
|
||||
|
||||
**3. CPU 频率调节模式 (Frequency Scaling Governor)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **预期信息**：确认 CPU 调频策略。应为 `performance`（定频/高性能）。若为 `powersave` 或 `ondemand`，CPU 频率随负载波动会破坏信号处理的时间确定性（Jitter）。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor | sort | uniq
|
||||
performance
|
||||
```
|
||||
|
||||
**4. 自动 NUMA 平衡策略 (Automatic NUMA Balancing)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **预期信息**：返回 `0` (禁用) 或 `1` (启用)。在实时系统中应设为 `0`。若启用，内核会自动迁移内存页以试图优化局部性，这会引发不可控的 Page Fault 和延迟，严重干扰 DSP 算法运行。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
cat /proc/sys/kernel/numa_balancing
|
||||
1
|
||||
```
|
||||
|
||||
**5. 实时调度节流阈值 (Real-time Throttling)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **预期信息**：默认通常为 `950000` (μs)，即预留 5% CPU 给非实时任务。若雷达处理线程独占核心且需 100% 占用（死循环轮询），需设为 `-1` 以关闭节流，否则线程会被强制挂起。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
cat /proc/sys/kernel/sched_rt_runtime_us
|
||||
950000
|
||||
```
|
||||
|
||||
**6. 中断负载均衡服务状态 (IRQ Balance Service)**
|
||||
|
||||
- **关键性**：P2
|
||||
- **预期信息**：确认 `irqbalance` 服务状态。对于高性能网卡或 PCIe 采集卡，通常需要关闭自动均衡，手动将硬中断（IRQ）绑定到特定核心，以避免中断处理在不同核心间漂移导致缓存失效。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
systemctl status irqbalance 2>/dev/null | grep -E "Active|Loaded"
|
||||
Loaded: loaded (/usr/lib/systemd/system/irqbalance.service; enabled; vendor preset: enabled)
|
||||
Active: active (running) since Wed 2025-11-19 14:12:35 CST; 1h 41min ago
|
||||
```
|
||||
|
||||
**7. 离线核心状态 (Offline CPUs)**
|
||||
|
||||
- **关键性**：P2
|
||||
- **预期信息**：检查是否有核心被逻辑关闭（Hotplug off）。这有时用于节能或规避硬件故障，需确认所有预期可用的物理核心均处于 Online 状态（此处为空表示全在线）。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
cat /sys/devices/system/cpu/offline
|
||||
|
||||
```
|
||||
|
||||
**8. 现有实时进程分布 (Existing RT Processes)**
|
||||
|
||||
- **关键性**：P2
|
||||
- **预期信息**：扫描当前系统中是否已有运行在 `RR` (Round Robin) 或 `FIFO` 策略下的实时进程，防止它们与未来的雷达业务产生资源争抢。
|
||||
- 探测命令：
|
||||
|
||||
```bash
|
||||
ps -eo pid,cls,rtprio,cmd --sort=-rtprio | grep -E "RR|FF" | head -n 10
|
||||
13 FF 99 [migration/0]
|
||||
16 FF 99 [migration/1]
|
||||
21 FF 99 [migration/2]
|
||||
26 FF 99 [migration/3]
|
||||
31 FF 99 [migration/4]
|
||||
36 FF 99 [migration/5]
|
||||
41 FF 99 [migration/6]
|
||||
46 FF 99 [migration/7]
|
||||
51 FF 99 [migration/8]
|
||||
56 FF 99 [migration/9]
|
||||
```
|
||||
|
||||
145
系统基座文件/1/1.1/1.1.4 系统级资源限制 (System Resource Limits).md
Normal file
145
系统基座文件/1/1.1/1.1.4 系统级资源限制 (System Resource Limits).md
Normal file
@@ -0,0 +1,145 @@
|
||||
---
|
||||
tags:
|
||||
date created: 星期三, 十一月 19日 2025, 3:57:04 下午
|
||||
date modified: 星期三, 十一月 19日 2025, 4:02:26 下午
|
||||
---
|
||||
|
||||
# 1.1.4 系统级资源限制 (System Resource Limits)
|
||||
|
||||
**1. 进程级资源配额 (Process Limits / ulimit)**
|
||||
|
||||
- **关键性**：P0
|
||||
- **信息解析**：
|
||||
- **关键风险点**：`max locked memory` (锁定内存) 仅为 **64KB**。这是致命配置。雷达实时程序必须通过 `mlock()` 锁定物理内存以防止被 Swap 换出。此限制会导致锁定失败，进而引发不可控的缺页中断（Page Fault），破坏实时性。
|
||||
- **有利配置**：`open files` (文件句柄) 已达 **524288**，`core file size` 为 `unlimited`，这有利于高并发 Socket 通信和崩溃现场保留。
|
||||
- **注意点**：`stack size` 为 **8192KB (8MB)**。对于深度递归或在栈上分配大型矩阵的 DSP 算法，可能面临 Stack Overflow 风险，建议在工程中调整或改为堆分配。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
ulimit -a
|
||||
core file size (blocks, -c) unlimited
|
||||
data seg size (kbytes, -d) unlimited
|
||||
scheduling priority (-e) 0
|
||||
file size (blocks, -f) unlimited
|
||||
pending signals (-i) 255853
|
||||
max locked memory (kbytes, -l) 64
|
||||
max memory size (kbytes, -m) unlimited
|
||||
open files (-n) 524288
|
||||
pipe size (512 bytes, -p) 8
|
||||
POSIX message queues (bytes, -q) 819200
|
||||
real-time priority (-r) 0
|
||||
stack size (kbytes, -s) 8192
|
||||
cpu time (seconds, -t) unlimited
|
||||
max user processes (-u) 255853
|
||||
virtual memory (kbytes, -v) unlimited
|
||||
file locks (-x) unlimited
|
||||
```
|
||||
|
||||
**2. 系统级文件句柄上限 (System-wide File Handles)**
|
||||
|
||||
- **关键性**：P2
|
||||
- **信息解析**：
|
||||
- `file-max` 约为 $9.22 \times 10^{18}$，`nr_open` 约为 $10.7$ 亿。
|
||||
- 结论：内核层面的文件描述符限制极其宽裕，不存在系统级瓶颈。任何 "Too many open files" 错误均将源自进程级（ulimit）限制。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
cat /proc/sys/fs/file-max
|
||||
9223372036854775807
|
||||
```
|
||||
|
||||
```bash
|
||||
cat /proc/sys/fs/nr_open
|
||||
1073741816
|
||||
```
|
||||
|
||||
**3. 线程与进程容量 (Thread & Process Capacity)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **信息解析**：
|
||||
- `pid_max` (419 万) 和 `threads-max` (51 万) 提供了充足的 ID 空间。
|
||||
- 结论：系统支持高并发多线程模型，能够容纳雷达处理管线中密集的数据分发线程。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
cat /proc/sys/kernel/pid_max
|
||||
4194304
|
||||
```
|
||||
|
||||
```bash
|
||||
cat /proc/sys/kernel/threads-max
|
||||
511707
|
||||
```
|
||||
|
||||
**4. 核心转储策略 (Core Dump Strategy)**
|
||||
|
||||
- **关键性**：P2
|
||||
- **信息解析**：
|
||||
- `core_pattern` 被重定向至 `systemd-coredump`。这意味着 Core 文件会被压缩并统一存储在 `/var/lib/systemd/coredump/`，而非散落在当前目录。这对长期运行的无人值守系统有利，便于统一回溯。
|
||||
- `suid_dumpable` 为 `0`。这意味着如果雷达主程序使用了 `setuid` 提权或文件 capabilities，崩溃时将**不会**产生 Core Dump。调试阶段建议临时设为 `1`。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
cat /proc/sys/kernel/core_pattern
|
||||
|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
|
||||
```
|
||||
|
||||
```bash
|
||||
cat /proc/sys/fs/suid_dumpable
|
||||
0
|
||||
```
|
||||
|
||||
**5. 管道缓冲区限制 (Pipe Buffer Limits)**
|
||||
|
||||
- **关键性**：P2
|
||||
- **信息解析**：
|
||||
- `pipe-max-size` 为 **1MB**。
|
||||
- 结论：如果进程间通信（IPC）大量依赖 Pipe，单次原子写入不应超过此值。对于高吞吐雷达数据，建议使用共享内存而非管道。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
cat /proc/sys/fs/pipe-max-size
|
||||
1048576
|
||||
```
|
||||
|
||||
**6. System V IPC 限制 (Shared Memory & Semaphores)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **信息解析**：
|
||||
- **共享内存**：最大段大小 (Max Segment Size) 极为巨大（PB 级），完全满足 GPGPU 异构计算中零拷贝（Zero-copy）或大块内存共享的需求。
|
||||
- **消息队列**：`max message size` 仅为 **8192 字节**。这表明 System V 消息队列仅适用于传递极小的控制指令（Control Plane），严禁用于传输雷达回波数据（Data Plane）。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
ipcs -l
|
||||
---------- 消息限制 -----------
|
||||
系统最大队列数量 = 32000
|
||||
最大消息尺寸 (字节) = 8192
|
||||
默认的队列最大尺寸 (字节) = 16384
|
||||
|
||||
---------- 同享内存限制 ------------
|
||||
最大段数 = 4096
|
||||
最大段大小 (千字节) = 18014398509465599
|
||||
最大总共享内存 (千字节) = 18014398509481920
|
||||
最小段大小 (字节) = 1
|
||||
|
||||
--------- 信号量限制 -----------
|
||||
最大数组数量 = 32000
|
||||
每个数组的最大信号量数目 = 32000
|
||||
系统最大信号量数 = 1024000000
|
||||
每次信号量调用最大操作数 = 500
|
||||
信号量最大值=32767
|
||||
```
|
||||
|
||||
**7. 持久化资源配置文件 (Persistent Config File)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **信息解析**：
|
||||
- 输出为空。说明 `/etc/security/limits.conf` 中没有显式配置。
|
||||
- 结论：当前的系统限制值（如 `open files = 524288`）可能来自于 systemd 的全局默认配置或 `/etc/security/limits.d/` 下的子文件。但 `memlock` 的 64KB 限制必须在此文件中显式覆盖，否则每次重启都会面临实时性风险。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
grep -vE "^#|^$" /etc/security/limits.conf
|
||||
(空)
|
||||
```
|
||||
110
系统基座文件/1/1.1/1.1.5 设备节点与总线映射 (Device Nodes & Bus Mapping).md
Normal file
110
系统基座文件/1/1.1/1.1.5 设备节点与总线映射 (Device Nodes & Bus Mapping).md
Normal file
@@ -0,0 +1,110 @@
|
||||
---
|
||||
tags:
|
||||
date created: 星期三, 十一月 19日 2025, 4:05:45 下午
|
||||
date modified: 星期三, 十一月 19日 2025, 4:06:00 下午
|
||||
---
|
||||
|
||||
# 1.1.5 设备节点与总线映射 (Device Nodes & Bus Mapping)
|
||||
|
||||
**1. 核心加速卡与显示设备识别 (GPU & Display Recognition)**
|
||||
|
||||
- **关键性**：P0
|
||||
- **信息解析**：
|
||||
- **设备状态**：成功识别到 ID 为 `1e3e:0002` 的 Processing accelerator，此即 **天数智芯（Iluvatar）智铠 GPU**。物理总线地址为 `0001:01:00.0`。
|
||||
- **设备节点**：`/dev/iluvatar0` 已创建，且权限为 `666` (crw-rw-rw-)，这意味着用户态程序可以直接访问，驱动加载正常。
|
||||
- **显示设备**：检测到 Phytium 原生显示控制器 (`0001:02:00.0`)，映射为 `/dev/dri/card0`。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
lspci -nn | grep -E "VGA|3D|Display|Processing|Accelerator"
|
||||
0001:01:00.0 Processing accelerators [1200]: Device [1e3e:0002] (rev 01)
|
||||
0001:02:00.0 Display controller [0380]: Phytium Technology Co., Ltd. Device [1db7:dc3e]
|
||||
```
|
||||
|
||||
```bash
|
||||
ls -lR /dev/dri /dev/vfio /dev/iluvatar* 2>/dev/null
|
||||
crw-rw-rw- 1 root root 239, 0 11月 19 14:12 /dev/iluvatar0
|
||||
…
|
||||
```
|
||||
|
||||
**2. PCIe 链路带宽与完备性 (PCIe Link Status)**
|
||||
|
||||
- **关键性**：P0
|
||||
- **信息解析**：
|
||||
- **严重告警 (Network)**：`dmesg` 显示网迅网卡（ngbe）带宽受限。
|
||||
|
||||
> `8.000 Gb/s available PCIe bandwidth, limited by 5.0 GT/s PCIe x2 link`
|
||||
> 网卡能力为 x4，但实际协商或插槽仅支持 x2。**这导致物理带宽上限仅为 8Gbps，无法跑满双口万兆，雷达高吞吐传输存在丢包风险。**
|
||||
|
||||
- **链路降级 (Link Downgrade)**：`lspci` 统计显示有多个设备状态为 `downgraded`。需确认 GPU (`0001:01:00.0`) 当前是跑在 `Speed 16GT/s, Width x16` 还是被降级。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
dmesg | grep -iE "smmu|iommu|pci|aer|firmware" | tail -n 20
|
||||
[ 7.267461] ngbe 0000:0d:00.0: 8.000 Gb/s available PCIe bandwidth, limited by 5.0 GT/s PCIe x2 link at 0000:09:04.0
|
||||
```
|
||||
|
||||
```bash
|
||||
lspci -vv | grep -E "LnkCap:|LnkSta:" | grep -E "Speed|Width" | sort | uniq -c
|
||||
1 LnkSta: Speed 16GT/s (downgraded), Width x8 (ok)
|
||||
1 LnkSta: Speed 16GT/s (ok), Width x8 (downgraded)
|
||||
```
|
||||
|
||||
**3. IOMMU 组别与隔离 (IOMMU Groups)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **信息解析**：
|
||||
- **功能状态**：IOMMU 已激活。
|
||||
- **分组详情**：
|
||||
- GPU (`0001:01:00.0`) 被分配在 **Group 18**。
|
||||
- 网卡 (`0000:0d:00.x`) 被分配在 **Group 19**。
|
||||
- **结论**：GPU 独占 Group 18，这非常有利于通过 VFIO 进行直通（Passthrough）或用户态驱动开发，隔离性良好。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
dmesg | grep -iE "smmu|iommu|pci|aer|firmware"
|
||||
[ 6.942440] iommu: Adding device 0001:01:00.0 to group 18
|
||||
[ 7.112576] iommu: Adding device 0000:0d:00.0 to group 19
|
||||
```
|
||||
|
||||
**4. 中断亲和性与分布 (Interrupt Affinity)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **信息解析**：
|
||||
- **NVMe 风险**：NVMe SSD 的中断 (`nvme0q0`, IRQ 124) 在终端输出时刻仅触发在 CPU0 上（Count=37）。
|
||||
- **USB 干扰**：大量的 `xhci_hcd` (USB) 中断分布在 IRQ 128-146。
|
||||
- **建议**：必须将雷达的高速信号采集卡中断和 NVMe 落盘中断手动绑定到不同的 CPU 核心，避免与 CPU0（通常处理 OS 杂项）争抢。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
cat /proc/interrupts | grep -i "MSI" | head -n 20
|
||||
124: 37 0 … 0 ITS-MSI 135790592 Edge nvme0q0
|
||||
```
|
||||
|
||||
**5. 块设备 IO 调度器 (Block Device IO Scheduler)**
|
||||
|
||||
- **关键性**：P2
|
||||
- **信息解析**：
|
||||
- **NVMe 配置**：`nvme0n1` 当前调度器为 `[none]`。
|
||||
- **结论**：**优秀配置**。对于 NVMe SSD，使用 `none` (多队列直通) 能最大程度降低 CPU 开销，最适合雷达原始数据（Raw Data）的高速落盘场景。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
grep "" /sys/block/*/queue/scheduler
|
||||
/sys/block/nvme0n1/queue/scheduler:[none] mq-deadline kyber bfq
|
||||
```
|
||||
|
||||
**6. PCIe 最大有效载荷 (Max Payload Size)**
|
||||
|
||||
- **关键性**：P2
|
||||
- **信息解析**：
|
||||
- 多数设备协商在 `512 bytes`，但也有一部分在 `128 bytes` 或 `256 bytes`。
|
||||
- 若 GPU 或采集卡的 MPS (Max Payload Size) 不匹配（如一个 128 一个 512），PCIe 控制器会强制按照木桶效应（最低值）传输，导致 DMA 效率下降 15%-30%。需确认 GPU 具体协商值。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
lspci -vv | grep -E "DevCtl:|DevCap:" | grep -E "MaxPayload|MaxReadReq" | sort | uniq -c
|
||||
15 DevCap: MaxPayload 128 bytes…
|
||||
23 DevCap: MaxPayload 512 bytes…
|
||||
```
|
||||
|
||||
@@ -0,0 +1,92 @@
|
||||
---
|
||||
tags:
|
||||
date created: 星期三, 十一月 19日 2025, 4:10:16 下午
|
||||
date modified: 星期三, 十一月 19日 2025, 4:10:27 下午
|
||||
---
|
||||
|
||||
# 1.1.6 时间同步与系统关键疑点深挖 (Time Synchronization & Deep-Dive)
|
||||
|
||||
**1. 时间同步服务健康度 (Time Synchronization Health)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **信息解析**：
|
||||
- **时钟源 (Clocksource)**：系统正确使用了 `arch_sys_counter`，这是 ARM64 架构下的高精度硬件计数器，基准可靠。
|
||||
- **同步偏差 (Offset)**：当前与 NTP 服务器的偏差约为 **6ms - 7ms** (`-6106us` \~ `+7072us`)。对于毫秒级雷达应用尚可接受，但若涉及多站协同或相控阵微秒级同步，此偏差**过大**，建议改用 PTP (Precision Time Protocol) 或连接本地高精度 GPS 时钟源。
|
||||
- **频率漂移 (Frequency Skew)**：`89.988 ppm`，表明本地晶振走得稍快，但在 Chrony 修正范围内。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
|
||||
arch_sys_counter
|
||||
|
||||
chronyc sources -v
|
||||
^* 113.141.164.38 … -6106us[-6155us] +/- 35ms
|
||||
^+ 223.4.249.80 … +7072us[+7072us] +/- 34ms
|
||||
```
|
||||
|
||||
**2. GPU 链路降级确认 (GPU Link Downgrade Verification)**
|
||||
|
||||
- **关键性**：P0 (Critical)
|
||||
- **信息解析**：
|
||||
- **链路状态**：明确确证 **GPU 运行在 PCIe 4.0 x8 模式** (`Speed 16GT/s (ok), Width x8 (downgraded)`)。
|
||||
- **根本原因**：物理插槽可能仅为 `x8` 电气连接，或者 GPU 金手指接触不良，亦或是主板 BIOS 设置了通道拆分（Bifurcation）。
|
||||
- **后果**：理论带宽上限从 32GB/s (x16) 降至 16GB/s (x8)。若雷达回波数据量巨大（如多通道宽带信号），这将成为数据传输的硬瓶颈。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
lspci -s 0001:01:00.0 -vv | grep -E "LnkCap:|LnkSta:"
|
||||
LnkCap: Port #0, Speed 16GT/s, Width x16 …
|
||||
LnkSta: Speed 16GT/s (ok), Width x8 (downgraded)
|
||||
```
|
||||
|
||||
**3. 系统性能配置档 (System Performance Profile)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **信息解析**：
|
||||
- **激活策略**：`throughput-performance` 已激活。
|
||||
- **缺陷**：尽管使用了高性能配置，但前序审计发现 `numa_balancing=1` 依然开启。这说明 Kylin 默认的 `throughput-performance` 策略并未激进地关闭 NUMA 自动均衡，后续需创建自定义 Tuned Profile 来覆盖此项。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
tuned-adm active
|
||||
Current active profile: throughput-performance
|
||||
```
|
||||
|
||||
**4. 透明大页整理策略 (THP Defrag Policy)**
|
||||
|
||||
- **关键性**：P2
|
||||
- **信息解析**：
|
||||
- **当前状态**：`[madvise]`。
|
||||
- **评价**：这是一个**相对安全**的设置。意味着内核仅在应用程序通过 `madvise(MADV_HUGEPAGE)` 显式请求时才整理大页，避免了全局强制整理带来的随机延迟。与 1.1.2 节建议一致。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
cat /sys/kernel/mm/transparent_hugepage/defrag
|
||||
always defer defer+madvise [madvise] never
|
||||
```
|
||||
|
||||
**5. 网络接口映射概览 (Network Interface Mapping)**
|
||||
|
||||
- **关键性**：P2
|
||||
- **信息解析**：
|
||||
- **接口列表**：
|
||||
- `ens4f0` - `ens4f3`：这极有可能是那是那块**带宽受限**的网迅四口千兆/万兆网卡。目前 `ens4f1` 为 `UP` 状态。
|
||||
- `ens2f7u1u2`：USB 网卡或转接设备，当前处于 `UP` 状态。
|
||||
- **下一步行动**：后续网络调优时，需重点针对 `ens4f*` 系列接口使用 `ethtool` 检查 Ring Buffer 大小和硬中断聚合（Coalesce）设置。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
ip -br link show
|
||||
ens4f0 DOWN …
|
||||
ens4f1 UP …
|
||||
```
|
||||
|
||||
-----
|
||||
|
||||
### 1\. 开发环境与构建生态 - 审计总结
|
||||
|
||||
至此，**1.1 操作系统与内核基座** 的深度审计已全部完成。我们已经掌握了这台机器的“体检报告”：
|
||||
|
||||
- **底座**：Kylin V10 SP1 (aarch64), Kernel 4.19 (GCC 7.3 构建), **64KB PageSize**。
|
||||
- **算力**：Feiteng S5000C + Iluvatar 智铠 GPU (PCIe x8 降级运行)。
|
||||
- **风险**：PageSize 兼容性、GPU 带宽减半、NVMe 中断挤压在 CPU0、系统时钟偏差较大。
|
||||
@@ -0,0 +1,64 @@
|
||||
---
|
||||
tags: []
|
||||
aliases:
|
||||
- 1.1.7 实时性与吞吐量配置补丁 (Real-time & Throughput Patches)
|
||||
date created: 星期三, 十一月 19日 2025, 4:31:12 下午
|
||||
date modified: 星期三, 十一月 19日 2025, 4:31:40 下午
|
||||
---
|
||||
|
||||
# 1.1.7 实时性与吞吐量配置补丁 (Real-time & Throughput Patches)
|
||||
|
||||
| **组件** | **状态** | **说明** |
|
||||
| :--- | :--- | :--- |
|
||||
| **limits.conf** | 已修复 | 解决了 `max locked memory` 64KB 的致命限制。 |
|
||||
| **sysctl.conf** | 已优化 | 解决了 `numa_balancing` 抖动和网络缓冲不足的问题。 |
|
||||
| **GRUB CMDLINE** | 已加固 | 解决了 USB 设备的自动挂起风险。 |
|
||||
|
||||
-----
|
||||
|
||||
**1. 进程级资源锁定限制 (Process Memory Locking)**
|
||||
|
||||
- **关键性**：P0
|
||||
- **信息解析**：已通过修改 `/etc/security/limits.conf`，将**锁定内存限制**从原先的致命值 **64KB** 提升至 `unlimited`。这确保了雷达实时线程和 DMA 缓冲区能成功调用 `mlock()`，杜绝内存换出导致的延迟。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
ulimit -l
|
||||
unlimited
|
||||
```
|
||||
|
||||
**2. 核心调度与实时节流策略 (CPU Scheduling & Throttling)**
|
||||
|
||||
- **关键性**：P0
|
||||
- **信息解析**：已停止并禁用 `irqbalance` 服务，并强制将内核 `numa_balancing` 设置为 `0`，消除了自动化的内存和中断迁移，以保障信号处理的时序确定性。同时，通过 `sched_rt_runtime_us = -1` 解除了对实时线程的 CPU 时间节流。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
systemctl status irqbalance | grep Active
|
||||
Active: inactive (dead) since …
|
||||
|
||||
sysctl kernel.numa_balancing
|
||||
kernel.numa_balancing = 0
|
||||
```
|
||||
|
||||
**3. 网络 UDP 缓冲区优化 (Network UDP Buffers)**
|
||||
|
||||
- **关键性**：P1
|
||||
- **信息解析**：已通过 `/etc/sysctl.d/99-radar-tuning.conf` 文件，将内核接收 (`rmem_max`) 和发送 (`wmem_max`) 缓冲区最大值从默认值提升至 25MB 以上，同时优化了 ARP 表大小。这对于处理降级 PCIe 链路 上的雷达高速 UDP 数据流是必要的。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
sysctl net.core.rmem_max
|
||||
net.core.rmem_max = 26214400
|
||||
```
|
||||
|
||||
**4. 硬件电源管理修正 (USB Power Management)**
|
||||
|
||||
- **关键性**：P2
|
||||
- **信息解析**：已通过 GRUB 引导参数，追加 `usbcore.autosuspend=-1`。这防止了连接的 USB 设备（如网卡）因系统默认的节能策略而进入休眠，保障了数据流的持续性。
|
||||
- 探测命令与结果：
|
||||
|
||||
```bash
|
||||
cat /proc/cmdline
|
||||
… usbcore.autosuspend=-1 …
|
||||
```
|
||||
87
系统基座文件/1/1.2/1.2.1 Host 端编译器规范 (Host Compiler Spec).md
Normal file
87
系统基座文件/1/1.2/1.2.1 Host 端编译器规范 (Host Compiler Spec).md
Normal file
@@ -0,0 +1,87 @@
|
||||
---
|
||||
tags: []
|
||||
date created: 星期三, 十一月 19日 2025, 4:34:58 下午
|
||||
date modified: 星期三, 十一月 19日 2025, 4:49:09 下午
|
||||
---
|
||||
|
||||
# 1.2.1 Host 端编译器规范 (Host Compiler Spec)
|
||||
|
||||
**1. Host 编译器身份确证 (Host Compiler Identity)**
|
||||
|
||||
- **关键性**：**P0**
|
||||
- **信息解析**：
|
||||
- **绝对路径**：`/usr/bin/g++`。
|
||||
- **版本指纹**：**GCC 7.3.0 (aarch64)**。
|
||||
- **深度解读**：此版本与前序审计（1.1.1）中内核构建所用的编译器完全一致。这意味着用户态程序（Host Code）与内核态驱动（Kernel Module）拥有相同的 ABI（二进制接口）边界，极大降低了 `insmod` 时的版本冲突风险。
|
||||
- **探测命令与结果**：
|
||||
|
||||
```bash
|
||||
/usr/bin/g++ --version
|
||||
g++ (GCC) 7.3.0
|
||||
Copyright (C) 2017 Free Software Foundation, Inc.
|
||||
```
|
||||
|
||||
```bash
|
||||
ls -l /usr/bin/g++
|
||||
-rwxr-xr-x 4 root root 988400 2月 21 2022 /usr/bin/g++
|
||||
```
|
||||
|
||||
**2. 默认语言标准支持 (Default C++ Standard)**
|
||||
|
||||
- **关键性**：**P1**
|
||||
- **信息解析**：
|
||||
- **宏定义值**：`201402L`。
|
||||
- **标准映射**：对应 **C++14** (GNU++14)。
|
||||
- **工程约束**：当前环境默认支持 C++14 特性（如 `std::make_unique`, `lambda capture`）。若项目代码依赖 C++17（如 `std::filesystem`, `std::optional`），必须在 `CMakeLists.txt` 中显式配置 `set(CMAKE_CXX_STANDARD 17)`，否则将导致编译失败。
|
||||
- **探测命令与结果**：
|
||||
|
||||
```bash
|
||||
/usr/bin/g++ -dM -E -x c++ /dev/null | grep __cplusplus
|
||||
#define __cplusplus 201402L
|
||||
```
|
||||
|
||||
**3. Device 编译器与工具链锚定 (Device Compiler & Toolchain Binding)**
|
||||
|
||||
- **关键性**：**P0**
|
||||
- **信息解析**：
|
||||
- **编译器版本**：**Clang 18.1.8** (CoreX 4.3.8 Build)。这是一个非常新的版本，对现代 C++ 语法支持极佳。
|
||||
- **工具链锚定 (Crucial)**：`Selected GCC installation: /usr/lib/gcc/aarch64-linux-gnu/7.3.0`。
|
||||
- **深度解读**：这是异构编译中最关键的“握手”。Clang 本身不带标准库（libstdc++），它必须“借用”系统 GCC 的库。此处显示 Clang 已正确探测并绑定到了系统 GCC 7.3.0。若此处显示 `None` 或错误路径，链接阶段将必现 `undefined reference to std::…` 错误。
|
||||
- **探测命令与结果**：
|
||||
|
||||
```bash
|
||||
which clang++
|
||||
/usr/local/corex-4.3.8/bin/clang++
|
||||
```
|
||||
|
||||
```bash
|
||||
clang++ -v 2>&1 | grep "Selected GCC installation"
|
||||
Selected GCC installation: /usr/lib/gcc/aarch64-linux-gnu/7.3.0
|
||||
```
|
||||
|
||||
**4. 构建系统缓存状态 (Build System Cache State)**
|
||||
|
||||
- **关键性**：**P1**
|
||||
- **信息解析**：
|
||||
- **编译器锁定**：`CMAKE_CXX_COMPILER` 明确被锁定为 `/usr/bin/g++`，未被环境变量（如 `CC`/`CXX`）篡改为其他版本。
|
||||
- **发布模式优化**：`CMAKE_CXX_FLAGS_RELEASE` 设为 `-O3 -DNDEBUG`。对于雷达信号处理这类计算密集型任务，`-O3` 开启了循环向量化（Loop Vectorization），这对 ARM64 NEON 指令集优化至关重要。
|
||||
- **探测命令与结果**：
|
||||
|
||||
```bash
|
||||
grep -E "CMAKE_CXX_COMPILER|CMAKE_CXX_FLAGS" …/build/CMakeCache.txt
|
||||
CMAKE_CXX_COMPILER:STRING=/usr/bin/g++
|
||||
CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG
|
||||
```
|
||||
|
||||
**5. 产物真实性审计 (Artifact Verification)**
|
||||
|
||||
- **关键性**：**P2**
|
||||
- **信息解析**：
|
||||
- **二进制指纹**：`.o` 文件的 `.comment` 段中包含 `GCC: (GNU) 7.3.0`。
|
||||
- **结论**：这证实了最终生成的机器码确实是由 GCC 7.3 编译的，排除了 CMake 只是“看起来”配置了 g++ 但实际调用了其他编译器的可能性（这种情况在存在 `ccache` 或 `distcc` 时偶有发生）。
|
||||
- **探测命令与结果**：
|
||||
|
||||
```bash
|
||||
find … -name "*.o" … | grep "GCC: ("
|
||||
GCC: (GNU) 7.3.0
|
||||
```
|
||||
68
系统基座文件/1/1.2/1.2.2 Device 端编译器规范 (Device Compiler Spec).md
Normal file
68
系统基座文件/1/1.2/1.2.2 Device 端编译器规范 (Device Compiler Spec).md
Normal file
@@ -0,0 +1,68 @@
|
||||
---
|
||||
tags: []
|
||||
date created: 星期三, 十一月 19日 2025, 4:54:50 下午
|
||||
date modified: 星期三, 十一月 19日 2025, 5:09:06 下午
|
||||
---
|
||||
|
||||
# 1.2.2 Device 端编译器规范 (Device Compiler Spec)
|
||||
|
||||
**1. Device 编译器身份与警告 (Compiler Identity & Warnings)**
|
||||
|
||||
- **关键性**：**P0**
|
||||
- **信息解析**：
|
||||
- **编译器内核**：**Clang 18.1.8** (基于 LLVM 18)。这是一个非常激进的新版本，支持最新的 C++ 标准。
|
||||
- **关键迁移警告**：
|
||||
|
||||
> `clang++: warning: When compiling *.cu file for ivcore '-x cuda' need replace with '-x ivcore' …`
|
||||
|
||||
- **含义**：目前的构建方式使用了 `-x cuda` 标志，天数智芯编译器对此发出了**废弃警告**。
|
||||
- **行动项**：工程文件中应尽快将编译语言标志从 `-x cuda` 迁移为 `-x ivcore`，以防未来 SDK 更新导致构建中断。
|
||||
- **强制约束**: AI 生成的 CMakeLists.txt 中，所有 .cu 文件的编译命令必须使用 -x ivcore，严禁使用 -x cuda。
|
||||
- **探测命令与结果**：
|
||||
|
||||
```bash
|
||||
/usr/local/corex-4.3.8/bin/clang++ --version
|
||||
clang version 18.1.8 (4.3.8 …)
|
||||
```
|
||||
|
||||
**2. 运行时库映射 (Runtime Library Mapping)**
|
||||
|
||||
- **关键性**：**P0**
|
||||
- **信息解析**：
|
||||
- **库文件位置**：`/usr/local/corex/lib` (注意不是 `lib64`)。
|
||||
- **CUDA 兼容层 (Shim Layers)**：
|
||||
- `libcudart.so` -\> `libcudart.so.89`：存在。这是运行时 API 的入口。
|
||||
- `libcuda.so`：存在。这是驱动层 API 的入口。
|
||||
- `libcufft.so`, `libcublas.so`, `libcudnn.so`：全套数学库均已存在同名替换文件。
|
||||
- **智铠原生层 (Native Layers)**：
|
||||
- `libixthunk.so`：推测为内核态 Thunking 层，负责最终的 syscall 下发。
|
||||
- `libixcore.so` (via `libcv_ixcore`): 核心计算库。
|
||||
- **链接器支持**：发现了 `LLVMgold.so`，表明该环境支持 LTO (Link Time Optimization) 链接时优化。
|
||||
- **文件系统证据**：
|
||||
|
||||
```text
|
||||
/usr/local/corex/lib/libcudart.so -> libcudart.so.89
|
||||
/usr/local/corex/lib/libcuda.so
|
||||
/usr/local/corex/lib/libixthunk.so
|
||||
```
|
||||
|
||||
**3. 宏定义环境 (Macro Environment)**
|
||||
|
||||
- **关键性**：**P1**
|
||||
- **信息解析**：
|
||||
- **平台标识**：`__ILUVATAR__ = 1`。代码中可以用 `#ifdef __ILUVATAR__` 编写专用优化。
|
||||
- **兼容性标识**：`__CUDA__ = 1`，`__CUDACC__` 已定义。这是为了欺骗现有的 CUDA 代码，使其认为自己正在被 NVCC 编译。
|
||||
- **探测命令与结果**：
|
||||
|
||||
```bash
|
||||
clang++ -dM -E -x cuda /dev/null | grep "__ILUVATAR__"
|
||||
#define __ILUVATAR__ 1
|
||||
```
|
||||
|
||||
**4. 头文件搜索优先级 (Header Search Priority)**
|
||||
|
||||
- **关键性**：**P0**
|
||||
- **信息解析**：
|
||||
- **劫持机制**：编译器优先搜索 `/usr/local/corex-4.3.8/lib/clang/18/include/cuda_wrappers`。
|
||||
- **原理**：CoreX 在此目录下放置了与 CUDA 同名的头文件（如 `cuda_runtime.h`），拦截标准调用并映射到底层 Iluvatar Runtime。
|
||||
- **GCC 绑定**：后续搜索路径正确回落到 Host 端的 `/usr/lib/gcc/aarch64-linux-gnu/7.3.0/`，保证了与 Host 代码的 ABI 兼容。
|
||||
63
系统基座文件/1/1.2/1.2.3 链接器与加载器配置 (Linker & Loader).md
Normal file
63
系统基座文件/1/1.2/1.2.3 链接器与加载器配置 (Linker & Loader).md
Normal file
@@ -0,0 +1,63 @@
|
||||
---
|
||||
tags:
|
||||
date created: 星期三, 十一月 19日 2025, 5:03:58 下午
|
||||
date modified: 星期三, 十一月 19日 2025, 5:04:15 下午
|
||||
---
|
||||
|
||||
# 1.2.3 链接器与加载器配置 (Linker & Loader)
|
||||
|
||||
**1. 链接器身份与版本 (Linker Identity)**
|
||||
|
||||
- **关键性**：**P1**
|
||||
- **信息解析**：
|
||||
- **组件版本**：**GNU ld (Binutils) 2.34**。这是一个相对较新的版本，完全支持 AArch64 的各种重定位类型（Relocation Types）和 LTO 插件。
|
||||
- **兼容性**：与 GCC 7.3 和 Clang 18 均能良好配合。
|
||||
- **探测命令与结果**：
|
||||
|
||||
```bash
|
||||
ld --version
|
||||
GNU ld (GNU Binutils) 2.34
|
||||
```
|
||||
|
||||
**2. 二进制依赖解析 (Binary Dependency Analysis)**
|
||||
|
||||
- **关键性**：**P0**
|
||||
- **信息解析**：
|
||||
- **直接依赖 (NEEDED)**：`libcudart.so.2`。
|
||||
- **深度解读**：这非常有意思。编译器（Clang）在编译时似乎模仿了 CUDA 10.2 的 ABI 行为，或者链接了伪装成 10.2 版本的存根库。这是为了让旧的 CUDA 代码无缝迁移。
|
||||
- **运行时路径 (RPATH)**：`/usr/local/corex/lib`。
|
||||
- **评价**：**优秀配置**。CMake 构建脚本通过 `CMAKE_INSTALL_RPATH` 或自动计算，将 SDK 库路径硬编码到了 ELF 文件头中。这是避免“DLL 地狱”的最佳实践。
|
||||
- **探测命令与结果**：
|
||||
|
||||
```bash
|
||||
readelf -d …/bin/main_app | grep -E "RPATH|NEEDED"
|
||||
0x0000000000000001 (NEEDED) 共享库：[libcudart.so.2]
|
||||
0x000000000000000f (RPATH) Library rpath: [/usr/local/corex/lib]
|
||||
```
|
||||
|
||||
**3. 运行时加载器解析 (Runtime Loader Resolution)**
|
||||
|
||||
- **关键性**：**P0**
|
||||
- **信息解析**：
|
||||
- **解析结果**：`ldd` 显示 `libcudart.so.2` 被成功解析到了 `/usr/local/corex/lib/libcudart.so.2`。
|
||||
- **结论**：运行时链接器（ld-linux）在执行程序时，优先读取了 RPATH，找到了正确的文件，而没有去系统默认目录瞎找。程序**一定**能跑起来，不会报 `cannot open shared object file`。
|
||||
- **探测命令与结果**：
|
||||
|
||||
```bash
|
||||
ldd …/bin/main_app
|
||||
libcudart.so.2 => /usr/local/corex/lib/libcudart.so.2 (0x0000fffeda1a0000)
|
||||
```
|
||||
|
||||
**4. 系统级库路径污染 (System Library Path State)**
|
||||
|
||||
- **关键性**：**P2**
|
||||
- **信息解析**：
|
||||
- **环境变量**：`LD_LIBRARY_PATH` 被设置了多次重复的 `/usr/local/corex-4.3.8/lib`。
|
||||
- **风险**：虽然 RPATH 优先级高于 `LD_LIBRARY_PATH`，但这种冗余设置可能在调试（Debug）或运行其他未设置 RPATH 的工具时引发困惑。建议在 `.bashrc` 中清理去重。
|
||||
- **ld.so.conf**：系统中没有专门针对 corex 的 `.conf` 文件。这进一步凸显了 CMake 中设置 RPATH 的重要性——如果 CMake 没设 RPATH，程序必挂。
|
||||
- **探测命令与结果**：
|
||||
|
||||
```bash
|
||||
echo $LD_LIBRARY_PATH
|
||||
/usr/local/corex-4.3.8/lib:/usr/local/corex-4.3.8/lib:… (重复)
|
||||
```
|
||||
@@ -0,0 +1,45 @@
|
||||
# 1.2.4 混合编译兼容性 (Hybrid Compilation Compatibility)
|
||||
|
||||
**1. C++ 标准库 ABI 兼容性 (StdLib ABI Compatibility)**
|
||||
|
||||
- **关键性**：**P0** (Showstopper)
|
||||
- **信息解析**：
|
||||
- **GCC 状态**：`#define _GLIBCXX_USE_CXX11_ABI 1`
|
||||
- **Clang 状态**：`#define _GLIBCXX_USE_CXX11_ABI 1`
|
||||
- **深度解读**：这是混合编译成败的关键。GCC 5.1 引入了新版 `std::string` 和 `std::list` 实现（符合 C++11 标准），并使用 Dual ABI 机制。如果两个编译器此宏定义不一致（例如一个为 0 一个为 1），链接器将无法匹配标准库符号。
|
||||
- **结论**：两者完全对齐，**无需**在 CMake 中手动添加 `-D_GLIBCXX_USE_CXX11_ABI=0`。
|
||||
- **探测命令与结果**：
|
||||
```bash
|
||||
echo "#include <string>" | g++ … | grep ABI
|
||||
#define _GLIBCXX_USE_CXX11_ABI 1
|
||||
echo "#include <string>" | clang++ … | grep ABI
|
||||
#define _GLIBCXX_USE_CXX11_ABI 1
|
||||
```
|
||||
|
||||
**2. 目标架构与指令集基线 (Target Architecture Baseline)**
|
||||
|
||||
- **关键性**：**P1**
|
||||
- **信息解析**：
|
||||
- **宏定义检查**：两者均定义了 `__aarch64__` 和 `__ARM_ARCH 8`，且**均未定义** `__ARM_FEATURE_ATOMICS`。
|
||||
- **原子指令策略**：
|
||||
* 现代 ARMv8.1+ 引入了 LSE (Large System Extensions) 原子指令（如 `ldadd`, `cas`），性能远超传统的 LL/SC (Load-Link/Store-Conditional, 即 `ldxr/stxr`) 循环。
|
||||
* 由于宏缺失且 grep `ldadd` 无输出，说明两个编译器都**回退到了保守的 LL/SC 模式**。
|
||||
- **风险评估**：考虑到飞腾 S5000C 基于 ARMv8 架构，这种保守策略是**最安全**的。强制开启 LSE (`-march=armv8.1-a+lse`) 虽然可能提升原子计数器性能，但在旧微架构上会导致 `SIGILL` (非法指令崩溃)。
|
||||
- **探测命令与结果**：
|
||||
```bash
|
||||
g++ … | grep __ARM_FEATURE_ATOMICS
|
||||
(空) -> 未启用 LSE
|
||||
clang++ … | grep __ARM_FEATURE_ATOMICS
|
||||
(空) -> 未启用 LSE
|
||||
```
|
||||
|
||||
**3. 编译标志警告 (Compiler Flags Warning)**
|
||||
|
||||
- **关键性**：**P2**
|
||||
- **信息解析**：
|
||||
- **重复警告**：Clang 再次提示 `'-x cuda' will not be supported`。
|
||||
- **行动项**：在 **1.2.2** 中已记录，需在 `CMakeLists.txt` 中修正语言标志。
|
||||
- **探测命令与结果**：
|
||||
```text
|
||||
clang++: warning: … need replace with '-x ivcore' …
|
||||
```
|
||||
66
系统基座文件/1/1.3/1.3.1 驱动核心模块状态 (Driver Kernel Modules).md
Normal file
66
系统基座文件/1/1.3/1.3.1 驱动核心模块状态 (Driver Kernel Modules).md
Normal file
@@ -0,0 +1,66 @@
|
||||
---
|
||||
tags:
|
||||
date created: 星期三, 十一月 19日 2025, 5:27:53 下午
|
||||
date modified: 星期三, 十一月 19日 2025, 5:28:03 下午
|
||||
---
|
||||
|
||||
# 1.3.1 驱动核心模块状态 (Driver Kernel Modules)
|
||||
|
||||
**1. 驱动加载与版本一致性 (Driver Load & Consistency)**
|
||||
|
||||
- **关键性**：**P0**
|
||||
- **信息解析**：
|
||||
- **核心状态**：驱动 `iluvatar` (v4.3.8) 已成功加载。
|
||||
- **健康自检**：dmesg 明确输出 `iluvatar 0001:01:00.0: DEV-0 is okay.`，标志着硬件初始化通过，未遇到固件加载错误。
|
||||
- **签名警告**：`module verification failed` 提示内核被“污染（tainted）”，这是因为使用了厂商提供的 Out-of-tree 非开源驱动。在开发环境中可忽略，生产环境若有强安全合规要求需进行自签名。
|
||||
- **探测命令与结果**：
|
||||
|
||||
```bash
|
||||
dmesg | grep "iluvatar" | tail -n 5
|
||||
[ 6.657344] iluvatar 0001:01:00.0: enabling device (0000 -> 0002)
|
||||
[ 7.037538] iluvatar 0001:01:00.0: DEV-0 is okay.
|
||||
```
|
||||
|
||||
**2. 关键模块参数配置 (Key Module Parameters)**
|
||||
|
||||
- **关键性**：**P1**
|
||||
- **信息解析**：
|
||||
- **统一寻址 (UVA/VMM)**：`itr_enable_vmm_va:Y`。开启了虚拟内存管理，允许 GPU 直接访问进程虚拟地址空间，简化了 `cudaMallocManaged` 等 API 的实现。
|
||||
- **保留显存**：`itr_text_mem_size:512`。驱动预留了 512MB 显存用于存放指令代码（Text Segment）。对于显存较小的卡（如 8GB），这 0.5GB 的开销需计入总预算。
|
||||
- **功耗策略**：`power:0`。通常 0 代表高性能模式（关闭激进节能），这有利于雷达信号处理的实时性稳定性。
|
||||
- **探测命令与结果**：
|
||||
|
||||
```bash
|
||||
grep -r . /sys/module/iluvatar/parameters/
|
||||
/sys/module/iluvatar/parameters/itr_enable_vmm_va:Y
|
||||
/sys/module/iluvatar/parameters/itr_text_mem_size:512
|
||||
/sys/module/iluvatar/parameters/power:0
|
||||
```
|
||||
|
||||
**3. 设备节点与权限映射 (Device Nodes & Permissions)**
|
||||
|
||||
- **关键性**：**P0**
|
||||
- **信息解析**：
|
||||
- **用户态接口**：`/dev/iluvatar0` 已创建。
|
||||
- **权限状态**：`crw-rw-rw- (666)`。这意味着**任何用户**都可以提交 GPU 任务，无需加入特定组（如 `video` 组）。虽然方便开发，但在多用户服务器上存在安全隐患。
|
||||
- **PCI 绑定**：`/sys/bus/pci/…/driver` 链接正确指向了 `iluvatar` 驱动，确认设备未被 `pci-stub` 或 `vfio-pci` 错误抢占。
|
||||
- **探测命令与结果**：
|
||||
|
||||
```bash
|
||||
ls -l /dev/iluvatar0
|
||||
crw-rw-rw- 1 root root 239, 0 …
|
||||
```
|
||||
|
||||
**4. 虚拟化与直通依赖 (Virtualization Dependencies)**
|
||||
|
||||
- **关键性**：**P2**
|
||||
- **信息解析**：
|
||||
- **VFIO 栈**：`mdev` 和 `vfio` 模块被 `iluvatar` 依赖。
|
||||
- **架构意义**：这表明智铠驱动采用了现代化的 **MDEV (Mediated Device)** 架构设计。即使在物理机上，它也可能利用 VFIO 框架来管理 DMA 和中断，这为将来在 Docker 容器或 KVM 虚拟机中直通 GPU 提供了原生支持。
|
||||
- **探测命令与结果**：
|
||||
|
||||
```bash
|
||||
lsmod | grep iluvatar
|
||||
iluvatar 983040 0
|
||||
vfio 262144 3 vfio_mdev,vfio_iommu_type1,iluvatar
|
||||
```
|
||||
@@ -0,0 +1,61 @@
|
||||
---
|
||||
tags: []
|
||||
date created: 星期三, 十一月 19日 2025, 5:29:54 下午
|
||||
date modified: 星期三, 十一月 19日 2025, 5:30:07 下午
|
||||
---
|
||||
|
||||
# 1.3.2 运行时环境与兼容层 (Runtime Environment & Shim Layer)
|
||||
|
||||
**1. 环境变量配置 (Environment Configuration)**
|
||||
|
||||
- **关键性**：**P1**
|
||||
- **信息解析**：
|
||||
- [cite\_start]**SDK 根路径**：`COREX_HOME` 被正确设置为 `/usr/local/corex` [cite: 1]。这是许多第三方构建脚本查找头文件和库的依据。
|
||||
- [cite\_start]**库搜索路径**：`LD_LIBRARY_PATH` 包含 `/usr/local/corex/lib` [cite: 1]，确保了在未设置 RPATH 的情况下也能找到 SDK 库。
|
||||
- **探测命令与结果**：
|
||||
|
||||
```bash
|
||||
env | grep "COREX"
|
||||
COREX_HOME=/usr/local/corex
|
||||
```
|
||||
|
||||
**2. 驱动层转发机制 (Driver Shim Mechanism)**
|
||||
|
||||
- **关键性**：**P0**
|
||||
- **信息解析**：
|
||||
- [cite\_start]**转发确认**：`libcuda.so` (即 NVIDIA Driver API 的替代品) 显式依赖于 `libixthunk.so` [cite: 1]。
|
||||
- **架构意义**：这是智铠 SDK 兼容 CUDA 的核心枢纽。它拦截了如 `cuMemAlloc`、`cuLaunchKernel` 等标准驱动调用，并通过 `libixthunk` 将其转换为发往 `iluvatar.ko` 内核模块的指令。
|
||||
- **探测命令与结果**：
|
||||
|
||||
```bash
|
||||
ldd /usr/local/corex/lib/libcuda.so
|
||||
libixthunk.so => /usr/local/corex/lib/libixthunk.so
|
||||
```
|
||||
|
||||
**3. 运行时版本伪装 (Runtime Version Masquerading)**
|
||||
|
||||
- **关键性**：**P0**
|
||||
- **信息解析**：
|
||||
- **金丝雀测试**：一个标准的 CUDA Runtime API 程序成功编译并运行。
|
||||
- [cite\_start]**版本欺骗**：系统返回 **Runtime Version: 10020** 和 **Driver Version: 10020** [cite: 1]。
|
||||
- **结论**：SDK 成功将自己伪装成了 **CUDA 10.2** 环境。这对于雷达信号处理算法库（如某些开源的 FFT 实现）至关重要，因为它们往往会对 CUDA 版本进行硬编码检查。
|
||||
- **探测命令与结果**：
|
||||
|
||||
```bash
|
||||
./test_runtime
|
||||
Detected CUDA Runtime Version: 10020
|
||||
Detected CUDA Driver Version: 10020
|
||||
```
|
||||
|
||||
**4. 运行时库依赖策略 (Runtime Library Strategy)**
|
||||
|
||||
- **关键性**：**P2**
|
||||
- **信息解析**：
|
||||
- [cite\_start]**依赖链**：`libcudart.so` 仅依赖标准系统库 (`libc`, `libstdc++` 等) [cite: 1]。
|
||||
- **推论**：不同于 `libcuda.so`，`libcudart` 可能设计得更为轻量，仅负责 API 的参数封装和管理，具体的硬件操作可能全部下沉到了驱动层库或通过动态加载实现。
|
||||
- **探测命令与结果**：
|
||||
|
||||
```bash
|
||||
ldd /usr/local/corex/lib/libcudart.so
|
||||
(无 libix* 显式依赖)
|
||||
```
|
||||
96
系统基座文件/1/1.3/1.3.3 管理与监控接口 (Management Interfaces).md
Normal file
96
系统基座文件/1/1.3/1.3.3 管理与监控接口 (Management Interfaces).md
Normal file
@@ -0,0 +1,96 @@
|
||||
---
|
||||
tags: []
|
||||
date created: 星期三, 十一月 19日 2025, 5:34:23 下午
|
||||
date modified: 星期三, 十一月 19日 2025, 6:29:11 晚上
|
||||
---
|
||||
|
||||
# 1.3.3 管理与监控接口 (Management Interfaces)
|
||||
|
||||
**1. 基础状态概览 (Basic Status Overview)**
|
||||
|
||||
- **关键性**：**P0**
|
||||
- **信息解析**：
|
||||
- **型号识别**：**Iluvatar MR-V100**。这是智铠的高端训练/推理卡。
|
||||
- **显存容量**：**32 GB** (32768 MiB)。对于雷达信号处理（如动目标检测 MTI、脉冲压缩），这是一个非常充裕的显存池，允许处理超大的相干处理间隔（CPI）数据块。
|
||||
- **热状态**：当前温度 **60°C**，风扇状态不可读 (N/A)。鉴于功耗仅 **41W** (空载)，温度略高，可能是被动散热或机房环境温度较高。
|
||||
- **探测命令与结果**：
|
||||
|
||||
```bash
|
||||
/usr/local/corex/bin/ixsmi
|
||||
| 0 Iluvatar MR-V100 | 00000001:01:00.0 |
|
||||
| N/A 60C P0 41W / 150W | 64MiB / 32768MiB |
|
||||
```
|
||||
|
||||
**2. ECC 错误监控能力 (ECC Monitoring Capability)**
|
||||
|
||||
- **关键性**：**P1**
|
||||
- **信息解析**：
|
||||
- **查询失败**：`Field "ecc.errors…" is not a valid field`。
|
||||
- **深度解读**：这意味着我们无法通过标准 SMI 命令监控显存的单比特翻转（Single Bit Error）。对于雷达这类对数据准确性敏感的系统，这是一个**盲区**。
|
||||
- **行动项**：在应用层代码中增加自校验逻辑（如周期性内存完整性测试），或联系厂商询问私有 ECC 查询接口。
|
||||
- **探测命令与结果**：
|
||||
|
||||
```bash
|
||||
ixsmi --query-gpu=ecc…
|
||||
Field … is not a valid field to query.
|
||||
```
|
||||
|
||||
**3. 频率与功耗详情 (Clock & Power)**
|
||||
|
||||
- **关键性**：**P1**
|
||||
- **信息解析**：
|
||||
- **核心频率**：当前 **1500 MHz**，最大 **1600 MHz**。GPU 几乎运行在全速状态（P0 态），性能释放良好。
|
||||
- **功耗墙**：默认上限 **150W**。相比 NVIDIA V100 (250W) 或 A100 (400W)，这张卡功耗较低，适合边缘侧雷达站部署。
|
||||
- **温度阈值**：**95°C** 开始降频 (Slowdown)，**105°C** 强制关机 (Shutdown)。当前 60°C 距离热墙尚远。
|
||||
- **探测命令与结果**：
|
||||
|
||||
```bash
|
||||
ixsmi -q -d CLOCK,POWER,TEMPERATURE
|
||||
GPU Power Draw : 41 W
|
||||
GPU Max Operating Temp : 95 C
|
||||
SM : 1500 MHz
|
||||
```
|
||||
|
||||
**4. NUMA 拓扑亲和性 (NUMA Affinity)**
|
||||
|
||||
- **关键性**：**P0**
|
||||
- **信息解析**：
|
||||
- **绑定关系**：GPU 0 绑定到 **NUMA Node 1**。
|
||||
- **核心范围**：**CPU 16-31**。
|
||||
- **工程约束**：在编写多线程雷达处理程序时，**严禁**将主处理线程调度到 CPU 0-15。若发生跨 Node 内存拷贝，带宽将受到 QPI/UPI 总线的严重制约（增加 20%-40% 的延迟）。必须使用 `numactl --cpunodebind=1` 或 `pthread_setaffinity_np` 强制绑定。
|
||||
- **探测命令与结果**：
|
||||
|
||||
```bash
|
||||
ixsmi topo -m
|
||||
GPU0 X 16-31 1
|
||||
```
|
||||
|
||||
**5. 进程监控 (Process Monitoring)**
|
||||
|
||||
- **关键性**：**P2**
|
||||
- **信息解析**：
|
||||
- **状态**：当前无运行进程 (`No running processes found`)。
|
||||
- **结论**：环境“干净”，无后台训练任务或僵尸进程占用显存，适合进行基准测试（Benchmark）或新业务部署。
|
||||
- **探测命令与结果**：
|
||||
|
||||
```bash
|
||||
ixsmi pmon
|
||||
(No entries)
|
||||
```
|
||||
|
||||
**6. 关键风险应对 (Critical Risk Response)**
|
||||
|
||||
**6.1 运维盲区：ECC 监控缺失**
|
||||
|
||||
- **风险定性**：**P1 (可靠性风险)**。`ixsmi` 工具当前不支持查询 ECC 错误字段，导致系统无法感知显存物理位翻转（Bit Flip），在雷达长时运行中存在数据静默错误的隐患。
|
||||
- **应对策略**：已向厂商咨询底层查询接口。在获得官方工具前，建议在应用层增加关键数据块（如原始回波数据）的 CRC32 完整性校验。
|
||||
|
||||
**6.2 架构陷阱：NUMA 拓扑失配**
|
||||
|
||||
- **风险定性**：**P0 (性能风险)**。`ixsmi topo` 确认 GPU 绑定在 **NUMA Node 1 (CPU 16-31)**。若程序默认在 Node 0 启动，跨 CPU 访问显存将导致 QPI/UPI 总线瓶颈，延迟增加且不可控。
|
||||
- **执行修正**：必须使用 `numactl` 强制绑定 CPU 亲和性。针对您的构建环境，启动命令应规范为：
|
||||
|
||||
```bash
|
||||
# 强制将进程绑定到 NUMA Node 1 (Core 16-31)
|
||||
numactl --cpunodebind=1 --membind=1 /home/Radar/workspace/signal-processing-demo/build/bin/main_app
|
||||
```
|
||||
69
系统基座文件/1/1.3/1.3.4 核心数学加速库 (Core Math Libraries).md
Normal file
69
系统基座文件/1/1.3/1.3.4 核心数学加速库 (Core Math Libraries).md
Normal file
@@ -0,0 +1,69 @@
|
||||
---
|
||||
tags: []
|
||||
date created: 星期三, 十一月 19日 2025, 6:38:56 晚上
|
||||
date modified: 星期三, 十一月 19日 2025, 6:39:15 晚上
|
||||
---
|
||||
|
||||
# 1.3.4 核心数学加速库 (Core Math Libraries)
|
||||
|
||||
**1. 数学库物理实体与映射 (Physical Library Mapping)**
|
||||
|
||||
- **关键性**：**P0**
|
||||
- **信息解析**：
|
||||
- **文件存在性**：`libcufft.so` (FFT) 和 `libcublas.so` (BLAS) 均存在于 `/usr/local/corex/lib`。
|
||||
- **版本伪装策略**：
|
||||
- `libcublas.so` -\> 链接至 `libcublas.so.2.3.254`（伪装 CUDA 10.2）。
|
||||
- `libcufft.so` -\> 链接至 `libcufft.so.1.2.89`（伪装 CUDA 10.1）。
|
||||
- **容量分析**：
|
||||
- `libcufft` 体积高达 **412MB**，`libcublas` 为 **133MB**。
|
||||
- **结论**：如此巨大的体积表明这**绝不是**简单的 API 转发层（Shim），而是包含完整数学算法实现的**重编译版本**（Native Implementation）。
|
||||
- **探测命令与结果**：
|
||||
|
||||
```bash
|
||||
ls -lh /usr/local/corex/lib/libcufft.so*
|
||||
-rwxr-xr-x … 412M … libcufft.so.1.2.89
|
||||
```
|
||||
|
||||
**2. 二进制身份指纹 (Binary Identity)**
|
||||
|
||||
- **关键性**：**P1**
|
||||
- **信息解析**：
|
||||
- **构建来源**：`strings` 命令输出显示包含 `iluvatar.version` 和 `clang version 18.1.8 (4.3.8 …)`。
|
||||
- **深度解读**：这证实了该库是由天数智芯（Iluvatar）使用其自研工具链（Clang 18 base）从源码重新编译的，而非 NVIDIA 的二进制文件。这意味着其底层实现已针对智铠 GPU 的 VLIW 架构进行了特定优化。
|
||||
- **探测命令与结果**：
|
||||
|
||||
```bash
|
||||
strings … | grep "iluvatar"
|
||||
iluvatar.version
|
||||
SDK Version
|
||||
```
|
||||
|
||||
**3. 开发头文件状态 (Header Availability)**
|
||||
|
||||
- **关键性**：**P0**
|
||||
- **信息解析**：
|
||||
- **状态**：`cufft.h` 和 `cublas_v2.h` 均存在且大小正常。
|
||||
- **兼容性**：这意味着现有的雷达信号处理代码（通常包含这两个头文件）无需修改 `#include` 路径即可直接编译。
|
||||
- **探测命令与结果**：
|
||||
|
||||
```bash
|
||||
ls -l …/include/cufft.h …/include/cublas_v2.h
|
||||
-rwxr-xr-x … 13033 … cufft.h
|
||||
```
|
||||
|
||||
**4. 功能性金丝雀测试 (Functional Canary Test)**
|
||||
|
||||
- **关键性**：**P0 (Critical)**
|
||||
- **信息解析**：
|
||||
- **测试内容**：同时调用 `cufftPlan1d` (创建 FFT 句柄) 和 `cublasCreate` (创建矩阵句柄)。
|
||||
- **测试结果**：
|
||||
- `cuFFT Plan1d: Success`
|
||||
- `cuBLAS Create: Success`
|
||||
- **审计结论**：**数学库功能完好**。链接器成功找到了库，且初始化函数能正确与驱动交互并分配资源。这是验证 SDK 可用性的里程碑。
|
||||
- **探测命令与结果**：
|
||||
|
||||
```bash
|
||||
./test_math
|
||||
cuFFT Plan1d: Success
|
||||
cuBLAS Create: Success
|
||||
```
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
tags:
|
||||
date created: 星期三, 十一月 19日 2025, 6:50:09 晚上
|
||||
date modified: 星期三, 十一月 19日 2025, 6:50:20 晚上
|
||||
---
|
||||
|
||||
# 1.3.5 开发者头文件与生态 (Developer Headers & Ecosystem)
|
||||
|
||||
**审计综述**：
|
||||
本环节确认了 SDK 对现代 C++ 开发生态的支持能力。最关键的发现是 **Thrust 模板库（v1.9.7）** 的完整存在且功能正常，这意味着雷达信号处理算法可以利用类似 STL 的高层抽象进行开发，而无需手写繁琐的 CUDA Kernel。同时，**FP16** 和 **标准数学函数** 的支持，保障了从 NVIDIA 平台迁移代码时的源码级兼容性。
|
||||
|
||||
**1. Thrust 模板库完备性 (Thrust Template Library)**
|
||||
|
||||
- **关键性**：**P0**
|
||||
- **信息解析**：
|
||||
- **版本指纹**：检测到 `THRUST_VERSION 100907`，对应 **Thrust v1.9.7**。这是一个非常成熟且广泛使用的版本（对应 CUDA 10.x 时代）。
|
||||
- **后端架构**：`THRUST_DEVICE_SYSTEM` 宏确认为 `CUDA` 后端。这表明智铠 SDK 实现了对 NVIDIA Thrust 接口的底层拦截与适配，开发者可以使用 `thrust::sort`, `thrust::reduce` 等高阶原语。
|
||||
- **功能验证**：金丝雀测试（Canary Test）成功在 Device 端完成了 Vector 数据拷贝与排序，证明 C++ 模板元编程在 `Clang++` 编译器下能正确展开并生成 GPU 指令。
|
||||
- **探测依据**：
|
||||
|
||||
```bash
|
||||
grep "THRUST_VERSION" /usr/local/corex/include/thrust/version.h
|
||||
#define THRUST_VERSION 100907
|
||||
ls -d /usr/local/corex/include/thrust
|
||||
/usr/local/corex/include/thrust
|
||||
```
|
||||
|
||||
**2. 混合精度计算支持 (Mixed Precision / FP16)**
|
||||
|
||||
- **关键性**：**P1**
|
||||
- **信息解析**：
|
||||
- **头文件状态**：`/usr/local/corex/include/cuda_fp16.h` 存在且文件大小正常（约 110KB）。
|
||||
- **业务价值**：在雷达数据存储（IQ 采样）和部分波束形成算法中，使用半精度（FP16）可将显存带宽需求降低 50%。该头文件的存在意味着我们可以定义 `__half` 类型并调用 `__hadd`, `__hmul` 等原生指令。
|
||||
- **探测依据**：
|
||||
|
||||
```bash
|
||||
ls -l /usr/local/corex/include/cuda_fp16.h
|
||||
-rwxr-xr-x 1 root root 110679 …
|
||||
```
|
||||
|
||||
**3. 设备端数学函数库 (Device Math Functions)**
|
||||
|
||||
- **关键性**：**P1**
|
||||
- **信息解析**：
|
||||
- **CRT 支持**：检测到 `crt/math_functions.h` (337KB) 和 `math_functions.h`。
|
||||
- **兼容性意义**：这些头文件映射了 C 标准数学库（如 `sinf`, `powf`, `sqrtf`）到 GPU 的硬件指令（SFU Special Function Units）。对于涉及大量三角函数运算的雷达信号处理（如相位解缠），这是必不可少的基础设施。
|
||||
- **探测依据**：
|
||||
|
||||
```bash
|
||||
ls -l /usr/local/corex/include/crt/math_functions.h
|
||||
-rwxr-xr-x 1 root root 337836 …
|
||||
```
|
||||
@@ -0,0 +1,49 @@
|
||||
---
|
||||
tags: []
|
||||
date created: 星期三, 十一月 19日 2025, 6:59:57 晚上
|
||||
date modified: 星期三, 十一月 19日 2025, 7:02:54 晚上
|
||||
---
|
||||
|
||||
# 1.3.6 官方示例与构建范式 (Official Samples & Build Patterns)
|
||||
|
||||
**审计综述**：
|
||||
由于系统中缺失官方 SDK 示例代码（`/usr/local/corex/samples` 不存在），我们将 **用户验证过的工程配置 (`SignalProject`)** 确立为该环境下的**标准构建范式（Golden Build Pattern）**。
|
||||
|
||||
**1. 核心构建策略：显式异构分离 (Explicit Heterogeneous Separation)**
|
||||
- **关键性**：**P0**
|
||||
- **范式解析**：
|
||||
- [cite_start]**Host 编译器**：显式锁定为 `/usr/bin/g++`。这是为了确保与 OS 内核（GCC 7.3 构建）的 ABI 完美兼容，避免 `libstdc++` 符号冲突。
|
||||
- [cite_start]**Device 编译器**：通过自定义变量 `CLANG_CUDA_COMPILER` 指向 `clang++`。这表明构建系统**没有**使用 CMake 原生的 `LANGUAGES CUDA` 支持（通常会自动寻找 nvcc），而是采用“C++ 项目 + 手动管理 GPU 编译规则”的模式。
|
||||
- [cite_start]**语言标准**：`project(SignalProject LANGUAGES CXX)`。项目本质被定义为 C++ 工程，GPU 代码被视为一种特殊的 C++ 扩展（ivcore/cuda）。
|
||||
|
||||
**2. SDK 路径管理 (SDK Path Management)**
|
||||
- **关键性**：**P1**
|
||||
- **范式解析**：
|
||||
- [cite_start]**硬编码路径**：SDK 根目录被锚定在 `/usr/local/corex`。
|
||||
- [cite_start]**头文件搜索**：显式定义 `COREX_INC_PATH` 用于查找 `cuda_runtime.h`。这与我们在 **1.3.5** 中发现的头文件位置一致。
|
||||
- [cite_start]**库文件搜索**：显式定义 `COREX_LIB_PATH`，配合 **1.2.3** 中验证过的 RPATH 机制，构成了完整的链接闭环。
|
||||
|
||||
**3. 依赖管理范式 (Dependency Management Pattern)**
|
||||
- **关键性**：**P2**
|
||||
- **范式解析**：
|
||||
- [cite_start]**GoogleTest 集成**：使用 `FetchContent` 在线拉取 `v1.14.0` 版本的 GTest。这意味着构建环境需要互联网连接，且该版本的 GTest 与当前的 GCC 7.3 / Clang 18 混合环境兼容。
|
||||
|
||||
**4. 结论与建议**
|
||||
- **当前状态**：构建范式已通过实战验证。
|
||||
- **行动项**：后续开发所有新模块时，**必须严格复制**此 `CMakeLists.txt` 中的编译器设置部分（特别是 `set(CMAKE_CXX_COMPILER …)` 和 `set(CLANG_CUDA_COMPILER …)`），任何试图引入 `enable_language(CUDA)` 或移除 GCC 显式指定的行为都极可能导致构建失败。
|
||||
|
||||
---
|
||||
|
||||
### 1.3 章节最终总结：GPGPU 软件开发套件
|
||||
|
||||
至此，我们完成了对 **1.3 GPGPU 软件开发套件** 的全方位审计：
|
||||
|
||||
1. **驱动 (Driver)**：`iluvatar.ko` (v4.3.8) 加载正常，但 NUMA 绑定需人工干预。
|
||||
2. **运行时 (Runtime)**：成功伪装为 **CUDA 10.2**，全链路金丝雀测试通过。
|
||||
3. **数学库 (Math)**：`cuFFT` / `cuBLAS` 的智铠原生重构版存在且可用，这是雷达业务的基石。
|
||||
4. **开发生态 (Ecosystem)**：`Thrust 1.9.7` 模板库就绪，支持高效率 C++ 开发。
|
||||
5. **构建范式 (Build)**：确立了 **"Host(GCC) + Device(Clang) + CoreX SDK"** 的混合编译标准。
|
||||
|
||||
**风险提示**：
|
||||
- **ECC 监控缺失**：需在软件层增加数据校验。
|
||||
- **NUMA 拓扑陷阱**：必须使用 `numactl` 或代码级绑定锁死 CPU 16-31。
|
||||
48
系统基座文件/1/1.4/1.4.1 CMake 核心环境 (CMake Core).md
Normal file
48
系统基座文件/1/1.4/1.4.1 CMake 核心环境 (CMake Core).md
Normal file
@@ -0,0 +1,48 @@
|
||||
---
|
||||
tags: []
|
||||
date created: 星期三, 十一月 19日 2025, 7:24:00 晚上
|
||||
date modified: 星期三, 十一月 19日 2025, 7:27:31 晚上
|
||||
---
|
||||
|
||||
# 1.4.1 CMake 核心环境 (CMake Core)
|
||||
|
||||
**1. 构建工具版本 (CMake Version)**
|
||||
|
||||
- **关键性**：**P1**
|
||||
- **信息解析**：
|
||||
- **物理版本**：**4.1.2**。这是一个非常新的版本（User Context 为 2025 年 11 月），意味着它原生支持现代 C++20/23 特性及最新的构建策略。
|
||||
- **项目约束**：`cmake_minimum_required(VERSION 3.10)`。
|
||||
- **结论**：版本兼容性极佳。CMake 4.x 完全向后兼容 3.x 语法。
|
||||
- **探测命令与结果**：
|
||||
|
||||
```bash
|
||||
cmake --version
|
||||
cmake version 4.1.2
|
||||
```
|
||||
|
||||
**2. 构建生成器 (Build Generator)**
|
||||
|
||||
- **关键性**：**P1**
|
||||
- **信息解析**：
|
||||
- **类型**：**Unix Makefiles**。
|
||||
- **评价**：这是 Linux 环境下的经典默认值。
|
||||
- **优化建议**：对于拥有 64 核以上的飞腾 S5000C 平台，若后续发现增量编译速度较慢，可考虑切换为 **Ninja** (`cmake -G Ninja …`)，其依赖分析速度通常优于 Make。目前保持 Makefiles 亦无大碍。
|
||||
- **探测命令与结果**：
|
||||
|
||||
```bash
|
||||
grep "CMAKE_GENERATOR" …/CMakeCache.txt
|
||||
CMAKE_GENERATOR:INTERNAL=Unix Makefiles
|
||||
```
|
||||
|
||||
**3. 工具链隔离状态 (Toolchain Isolation)**
|
||||
|
||||
- **关键性**：**P2**
|
||||
- **信息解析**：
|
||||
- **状态**：`CMAKE_TOOLCHAIN_FILE` 为空。
|
||||
- **架构意义**：这意味着 CMake 没有加载外部的交叉编译配置脚本。所有的编译器指定（Host GCC / Device Clang）均完全由项目内部的 `CMakeLists.txt` 显式控制。这符合“显式异构分离”的设计模式。
|
||||
- **探测命令与结果**：
|
||||
|
||||
```bash
|
||||
grep "CMAKE_TOOLCHAIN_FILE" …/CMakeCache.txt
|
||||
(Empty)
|
||||
```
|
||||
55
系统基座文件/1/1.4/1.4.2 编译器编排 (Compiler Orchestration).md
Normal file
55
系统基座文件/1/1.4/1.4.2 编译器编排 (Compiler Orchestration).md
Normal file
@@ -0,0 +1,55 @@
|
||||
---
|
||||
tags:
|
||||
aliases:
|
||||
- 1.4.2 异构编译器编排策略 (Heterogeneous Compiler Orchestration)
|
||||
date created: 星期三, 十一月 19日 2025, 7:27:38 晚上
|
||||
date modified: 星期三, 十一月 19日 2025, 7:42:22 晚上
|
||||
---
|
||||
|
||||
# 1.4.2 异构编译器编排策略 (Heterogeneous Compiler Orchestration)
|
||||
|
||||
**审计综述**：
|
||||
项目采用了\*\*“Host 主导，Device 旁路”\*\* 的编排模式。通过显式锁定 Host 编译器并禁用 CMake 原生 CUDA 支持，彻底规避了标准 `FindCUDA` 模块在国产异构环境下的兼容性问题。这种配置极其稳健，是当前环境下的最佳实践。
|
||||
|
||||
**1. Host 编译器锁定 (Host Compiler Locking)**
|
||||
|
||||
- **关键性**：**P0**
|
||||
- **策略解析**：
|
||||
- **配置**：`set(CMAKE_CXX_COMPILER "/usr/bin/g++")`。
|
||||
- **深度解读**：
|
||||
- **绝对路径**：使用了 `/usr/bin/g++`，消除了 `cc` 或 `c++` 软链接指向不明的风险。
|
||||
- **ABI 锚定**：强制使用系统 GCC，确保了与 OS 内核（GCC 7.3 构建）及系统库（libstdc++）的二进制兼容性。这是混合编译稳定性的基石。
|
||||
- **探测依据**：
|
||||
|
||||
```cmake
|
||||
set(CMAKE_CXX_COMPILER "/usr/bin/g++")
|
||||
```
|
||||
|
||||
**2. Device 编译器传递 (Device Compiler Passing)**
|
||||
|
||||
- **关键性**：**P1**
|
||||
- **策略解析**：
|
||||
- **配置**：`set(CLANG_CUDA_COMPILER "clang++")`。
|
||||
- **风险提示**：当前配置使用相对命令名。在多编译器共存的环境中（如同时安装了系统 Clang），可能导致误调用。建议优化为 `${COREX_PATH}/bin/clang++` 以实现物理隔离。
|
||||
- **角色**：此变量主要用于后续 `add_custom_command` 或自定义编译规则中，作为处理 `.cu` 文件的专用工具。
|
||||
- **探测依据**：
|
||||
|
||||
```cmake
|
||||
set(CLANG_CUDA_COMPILER "clang++")
|
||||
```
|
||||
|
||||
**3. 语言标准范围定义 (Language Scope Definition)**
|
||||
|
||||
- **关键性**：**P0**
|
||||
- **策略解析**：
|
||||
- **配置**：`project(SignalProject LANGUAGES CXX)`。
|
||||
- **核心逻辑**：
|
||||
- **仅启用 CXX**：明确告知 CMake 这是一个纯 C++ 项目。
|
||||
- **禁用 CUDA**：`grep "enable_language(CUDA)"` 为空，表明未启用 CMake 的原生 CUDA 支持。
|
||||
- **架构优势**：这避免了 CMake 试图去寻找 NVCC 或执行标准的 CUDA 设备链接（Device Linking）流程，从而让开发者完全掌控智铠 GPU 代码的编译参数（如 `-x ivcore`）。
|
||||
- **探测依据**：
|
||||
|
||||
```cmake
|
||||
project(SignalProject LANGUAGES CXX)
|
||||
# enable_language(CUDA) -> Not Found
|
||||
```
|
||||
55
系统基座文件/1/1.4/1.4.3 编译标志策略 (Flags Strategy).md
Normal file
55
系统基座文件/1/1.4/1.4.3 编译标志策略 (Flags Strategy).md
Normal file
@@ -0,0 +1,55 @@
|
||||
---
|
||||
tags:
|
||||
aliases:
|
||||
- 1.4.3 编译选项与性能开关 (Compilation Flags & Performance Switches)
|
||||
date created: 星期三, 十一月 19日 2025, 7:30:01 晚上
|
||||
date modified: 星期三, 十一月 19日 2025, 7:42:46 晚上
|
||||
---
|
||||
|
||||
# 1.4.3 编译选项与性能开关 (Compilation Flags & Performance Switches)
|
||||
|
||||
**审计综述**：
|
||||
当前构建系统在功能层面已适配智铠 SDK（正确使用了 `-x ivcore`），但在性能调优层面尚处于“默认状态”，缺失针对飞腾 CPU 的特定优化标志。
|
||||
|
||||
**1. Host 端编译标志策略 (Host Compilation Strategy)**
|
||||
|
||||
- **关键性**：**P1**
|
||||
- **策略解析**：
|
||||
- **构建类型管理**：正确区分了 `Release` (`-O3 -DNDEBUG`) 和 `Debug` (`-g`) 模式。CMake 默认的 Release 配置已开启最高等级的循环向量化优化。
|
||||
- **架构优化 (缺失)**：未检测到 `-march=armv8-a` 或 `-mtune=phytium`。
|
||||
- **改进建议**：建议显式添加 `-march=armv8-a` 以启用 ARMv8 指令集特性。鉴于 1.2.4 审计显示编译器未启用 LSE 原子指令，暂不建议添加 `+lse`，以免引入兼容性问题。
|
||||
- **警告等级 (缺失)**：主业务代码 (`signal_lib`) 未开启 `-Wall`，建议补全。
|
||||
- **探测依据**：
|
||||
|
||||
```bash
|
||||
grep "CMAKE_CXX_FLAGS_RELEASE" …/CMakeCache.txt
|
||||
CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG
|
||||
```
|
||||
|
||||
**2. Device 端方言与架构标志 (Device Dialect & Arch Flags)**
|
||||
|
||||
- **关键性**：**P0**
|
||||
- **策略解析**：
|
||||
- **核心方言标志**：检测到关键标志 **`-x ivcore`**。
|
||||
- **深度解读**：这是智铠编译器（Clang-based）识别 `.cu` 文件的“暗号”。不同于 NVCC 自动处理后缀，Clang 需要显式告知语言类型。该标志的存在证明构建脚本已针对 CoreX SDK v4.x 进行了正确适配。
|
||||
- **包含路径**：正确注入了 `-I/usr/local/corex/include`，确保 `cuda_runtime.h` 等头文件可见。
|
||||
- **位置无关代码**：虽然未显式 grep 到 `-fPIC`，但通常 CMake 处理动态库时会自动添加。若构建静态库（当前情况），此选项非必须。
|
||||
- **探测依据**：
|
||||
|
||||
```bash
|
||||
grep -r "clang++" …
|
||||
/bin/clang++ -x ivcore …
|
||||
```
|
||||
|
||||
**3. 宏定义管理 (Macro Management)**
|
||||
|
||||
- **关键性**：**P2**
|
||||
- **策略解析**：
|
||||
- **调试宏**：`NDEBUG` 在 Release 模式下正确定义，禁用了 `assert()` 检查，减少运行时开销。
|
||||
- **平台宏**：未在 CMake 中显式定义 `__ILUVATAR__`。这不是问题，因为 1.2.2 审计已确认 Device 编译器会在预处理阶段自动注入该宏。
|
||||
- **探测依据**：
|
||||
|
||||
```bash
|
||||
grep "CMAKE_CXX_FLAGS_RELEASE" …
|
||||
… -DNDEBUG
|
||||
```
|
||||
@@ -0,0 +1,70 @@
|
||||
---
|
||||
tags:
|
||||
aliases:
|
||||
- 1.4.4 依赖管理与链接逻辑 (Dependency Management & Linking Logic)
|
||||
date created: 星期三, 十一月 19日 2025, 7:48:04 晚上
|
||||
date modified: 星期三, 十一月 19日 2025, 7:48:14 晚上
|
||||
---
|
||||
|
||||
# 1.4.4 依赖管理与链接逻辑 (Dependency Management & Linking Logic)
|
||||
|
||||
**1. 依赖获取策略 (Dependency Acquisition Strategy)**
|
||||
|
||||
- **关键性**：**P1**
|
||||
- **策略解析**：
|
||||
- **在线拉取**：使用了现代 CMake 的 `FetchContent` 模块在线管理 GoogleTest。
|
||||
- **优势**：相比传统的 `ExternalProject_Add`，`FetchContent` 在配置阶段即下载源码，使得子项目可以直接参与主构建树的编译，非常适合 CI/CD 自动化环境。
|
||||
- **配置状态**：已配置 `gtest_force_shared_crt` 等缓存变量，确保运行时库兼容。
|
||||
- **探测依据**：
|
||||
|
||||
```cmake
|
||||
include(FetchContent)
|
||||
FetchContent_Declare(…)
|
||||
FetchContent_MakeAvailable(googletest)
|
||||
```
|
||||
|
||||
**2. 头文件暴露与隔离 (Header Visibility & Isolation)**
|
||||
|
||||
- **关键性**：**P0**
|
||||
- **策略解析**：
|
||||
- **目标级管理**：全面采用 `target_include_directories`。
|
||||
- **传递性控制**：
|
||||
- `signal_lib` 使用了 **PUBLIC** 属性。这意味着任何链接了 `signal_lib` 的目标（如 `main_app`），都会自动继承其头文件搜索路径。这是构建库（Library）的标准范式。
|
||||
- GTest 使用了 **SYSTEM INTERFACE**，有效屏蔽了第三方库可能产生的编译器警告。
|
||||
- **探测依据**：
|
||||
|
||||
```cmake
|
||||
target_include_directories(signal_lib PUBLIC …)
|
||||
```
|
||||
|
||||
**3. 链接传递性与作用域 (Linking Transitivity & Scope)**
|
||||
|
||||
- **关键性**：**P0**
|
||||
- **策略解析**：
|
||||
- **层级清晰**：
|
||||
- `signal_lib` 封装了底层的 SDK 细节（链接 `cudart`），对外暴露为高级接口。
|
||||
- `main_app` 仅需链接业务库 `signal_lib` 和系统库 `numa`，无需关心底层是否使用了 CUDA。
|
||||
- **链接模式**：
|
||||
- `main_app` 使用 **PRIVATE** 链接 `numa`（仅自己用，不传递）。
|
||||
- `signal_lib` 使用 **PUBLIC** 链接 `cudart`（依赖传递）。
|
||||
- **探测依据**：
|
||||
|
||||
```cmake
|
||||
target_link_libraries(main_app PRIVATE signal_lib numa)
|
||||
target_link_libraries(signal_lib PUBLIC cudart)
|
||||
```
|
||||
|
||||
**4. 运行时路径注入 (RPATH Mechanism)**
|
||||
|
||||
- **关键性**：**P0 (Critical)**
|
||||
- **策略解析**：
|
||||
- **物理状态**：`readelf` 确认二进制文件头部包含 `Library rpath: [/usr/local/corex/lib]`。
|
||||
- **生成机制**：尽管源码中未显式设置 `CMAKE_INSTALL_RPATH`，但由于链接时使用了库的绝对路径（推测 `cudart` 变量解析为 `/usr/local/corex/lib/libcudart.so`），CMake 默认会将非系统路径（Non-standard Path）自动添加到 Build Tree 的 RPATH 中。
|
||||
- **运维价值**：这确保了程序部署到生产环境时，**不需要**配置 `LD_LIBRARY_PATH` 环境变量即可运行，极大地降低了运维出错率。
|
||||
- **探测依据**：
|
||||
|
||||
```bash
|
||||
readelf -d …/bin/main_app | grep RPATH
|
||||
0x000000000000000f (RPATH) Library rpath: [/usr/local/corex/lib]
|
||||
```
|
||||
|
||||
@@ -0,0 +1,64 @@
|
||||
---
|
||||
tags: []
|
||||
date created: 星期三, 十一月 19日 2025, 7:50:36 晚上
|
||||
date modified: 星期三, 十一月 19日 2025, 7:51:09 晚上
|
||||
---
|
||||
|
||||
# 1.4.5 产物输出与安装规则 (Artifact Output & Installation Rules)
|
||||
|
||||
**审计综述**：
|
||||
项目采用了\*\*“集中式输出”**策略，极大地方便了开发阶段的调试与运行。然而，主构建脚本**完全缺失了安装规则 (`install`)\*\*，这意味着无法通过 `make install` 将产物打包或部署到系统目录，当前仅限于在构建目录（Build Tree）内运行。
|
||||
|
||||
**1. 输出目录布局 (Output Directory Layout)**
|
||||
|
||||
- **关键性**：**P1**
|
||||
- **策略解析**：
|
||||
- **集中管理**：通过设置 `CMAKE_RUNTIME_OUTPUT_DIRECTORY` 等变量，强制将所有生成物归档到 `${CMAKE_BINARY_DIR}/bin` 和 `${CMAKE_BINARY_DIR}/lib`。
|
||||
- **优势**：
|
||||
- 避免了编译产物散落在源码目录深处（In-source build pollution）。
|
||||
- 简化了 `RPATH` 的管理，因为所有库都在同一个相对路径下。
|
||||
- 方便了 `numactl` 等工具的调用路径书写（如 1.3.3 中所示）。
|
||||
- **探测依据**：
|
||||
|
||||
```cmake
|
||||
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
|
||||
```
|
||||
|
||||
**2. 安装规则状态 (Installation Rule Status)**
|
||||
|
||||
- **关键性**：**P2 (Missing)**
|
||||
- **策略解析**：
|
||||
- **现状**：`grep "install("` 显示主项目（`app` 和 `signal_lib`）**未定义任何安装规则**。仅有的安装指令来自第三方依赖（GTest）和 SDK 内部文件。
|
||||
- **影响**：运行 `make install` 将不会复制雷达主程序或库文件。对于目前的 Demo / 原型开发阶段，这是可接受的。
|
||||
- **改进建议**：若项目进入生产交付阶段，必须补充 `install(TARGETS main_app DESTINATION bin)` 等指令，以便生成发布包（RPM/DEB）。
|
||||
- **探测依据**：
|
||||
|
||||
```bash
|
||||
grep -r "install(" …
|
||||
# (无主项目相关输出)
|
||||
```
|
||||
|
||||
**3. 调试符号与剥离策略 (Debug Symbol Strategy)**
|
||||
|
||||
- **关键性**：**P2**
|
||||
- **策略解析**：
|
||||
- **物理状态**：`file` 命令显示 `not stripped`，说明符号表（Symbol Table）保留，可支持 `nm` 或 `gdb` 查看函数名堆栈。
|
||||
- **调试信息**：`readelf` 未找到 `.debug` 段。这是因为当前处于 **Release** 模式（`-O3 -DNDEBUG`），编译器默认不生成 DWARF 源码级调试信息。
|
||||
- **结论**：这是标准的 Release 构建产物，兼顾了性能（优化开启）和基础可维护性（崩溃时能看到函数名）。
|
||||
- **探测依据**：
|
||||
|
||||
```bash
|
||||
file …/main_app
|
||||
… not stripped
|
||||
```
|
||||
|
||||
-----
|
||||
|
||||
### 1.4 章节最终总结：构建系统与工程配置
|
||||
|
||||
至此，我们完成了对 **1.4 构建系统** 的全方位审计。我们确立了该项目的\*\*“构建基线”\*\*：
|
||||
|
||||
1. **核心**：CMake 4.1 + Unix Makefiles。
|
||||
2. **编排**：**Host(GCC) + Device(Clang) 显式分离**，禁用原生 CUDA 语言支持。
|
||||
3. **标志**：适配了 CoreX SDK 的 `-x ivcore` 方言，但缺少 Host 端的架构优化 (`-march=armv8-a`)。
|
||||
4. **布局**：产物集中输出到 `build/bin`，RPATH 自动注入，安装规则待补。
|
||||
@@ -0,0 +1,65 @@
|
||||
---
|
||||
tags:
|
||||
date created: 星期三, 十一月 19日 2025, 8:00:42 晚上
|
||||
date modified: 星期三, 十一月 19日 2025, 8:01:00 晚上
|
||||
---
|
||||
|
||||
# 1.5.1 系统运行时与 ABI 基线 (System Runtime & ABI Baseline)
|
||||
|
||||
**1. C++ 标准库 ABI 边界 (C++ StdLib ABI Horizon)**
|
||||
|
||||
- **关键性**：**P0**
|
||||
- **信息解析**：
|
||||
- **当前版本**：`GLIBCXX_3.4.24`。
|
||||
- **对应编译器**：**GCC 7.3.0**。
|
||||
- **工程约束**：
|
||||
- **C++ 标准**：完美支持 **C++14**。
|
||||
- **C++17 风险**：尽管 GCC 7.3 宣称支持 C++17，但 `std::filesystem` 等特性此时仍位于 `std::experimental` 命名空间，且 ABI 与 GCC 8/9（GLIBCXX\_3.4.26+）不兼容。
|
||||
- **第三方库选型**：在引入预编译的第三方库（如 TensorRT, Arrow）时，必须下载 **CentOS 7 / Ubuntu 18.04** 兼容版本，严禁使用依赖 GCC 9+ 的新版库，否则必报 `version 'GLIBCXX_3.4.26' not found`。
|
||||
- **探测依据**：
|
||||
|
||||
```bash
|
||||
strings /usr/lib64/libstdc++.so | grep "GLIBCXX" | tail -n 1
|
||||
GLIBCXX_3.4.24
|
||||
ls -l /usr/lib64/libstdc++.so
|
||||
… -> libstdc++.so.0.24
|
||||
```
|
||||
|
||||
**2. 系统基础 C 运行库 (System Glibc)**
|
||||
|
||||
- **关键性**：**P0**
|
||||
- **信息解析**：
|
||||
- **版本**：**glibc 2.28**。
|
||||
- **评价**：这是 Kylin V10 SP1 的出厂标配。相比 CentOS 7 的 glibc 2.17，它提供了更好的 `memcpy` 性能和更现代的 syscall 封装，足以支撑绝大多数现代雷达信号处理中间件。
|
||||
- **探测依据**：
|
||||
|
||||
```bash
|
||||
ldd --version
|
||||
ldd (GNU libc) 2.28
|
||||
```
|
||||
|
||||
**3. 安全与压缩基础设施 (Security & Compression Infra)**
|
||||
|
||||
- **关键性**：**P1**
|
||||
- **信息解析**：
|
||||
- **OpenSSL**：版本 **1.1.1f** (LTS)。支持 TLS 1.3。这是构建安全数据链路（如 HTTPS, Secure gRPC）的基石，且版本未过时，无需手动升级。
|
||||
- **Zlib**：版本 **1.2.11**。标准且稳定，用于 HDF5 或 Log 压缩无压力。
|
||||
- **探测依据**：
|
||||
|
||||
```bash
|
||||
openssl version
|
||||
OpenSSL 1.1.1f 31 Mar 2020
|
||||
```
|
||||
|
||||
**4. 全局库冲突检测 (Global Conflict Detection)**
|
||||
|
||||
- **关键性**：**P2**
|
||||
- **信息解析**：
|
||||
- **状态**：**Clean (无污染)**。
|
||||
- **解读**：在 `/usr/local` 下未发现“私藏”的 `libstdc++.so` 或 `libc.so`。这意味着系统加载器（Loader）不会因为搜索路径顺序问题加载到错误的运行时库，极大地降低了调试难度。
|
||||
- **探测依据**：
|
||||
|
||||
```bash
|
||||
find /usr/local -name "libstdc++.so*" …
|
||||
(Empty Result)
|
||||
```
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
tags:
|
||||
date created: 星期三, 十一月 19日 2025, 8:01:59 晚上
|
||||
date modified: 星期三, 十一月 19日 2025, 8:10:41 晚上
|
||||
---
|
||||
|
||||
# 1.5.2 Host 端信号处理与数学库 (Host Signal Processing & Math Libs)
|
||||
|
||||
**1. 快速傅里叶变换库 (FFTW3)**
|
||||
|
||||
- **关键性**：**P0**
|
||||
- **信息解析**：
|
||||
- **版本**：**3.5.8**。这是 FFTW3 系列非常稳定的版本。
|
||||
- **精度支持**：
|
||||
- `libfftw3f.so` (单精度 float)：用于处理雷达原始 IQ 数据（通常为 float 或 int16）。
|
||||
- `libfftw3.so` (双精度 double)：用于高精度后处理算法。
|
||||
- `libfftw3l.so` (长双精度 long double)：用于极端精度需求（较少用）。
|
||||
- **并行能力**：提供了 `_omp` (OpenMP) 和 `_threads` (Pthreads) 版本。建议在代码中优先链接 `libfftw3f_omp` 以利用多核优势。
|
||||
- **探测依据**：
|
||||
|
||||
```bash
|
||||
ls -l /usr/lib64/libfftw3f.so
|
||||
… libfftw3f.so.5.8
|
||||
```
|
||||
|
||||
**2. 线性代数加速库 (OpenBLAS)**
|
||||
|
||||
- **关键性**：**P0**
|
||||
- **信息解析**：
|
||||
- **版本**：**0.3.10**。
|
||||
- **架构优化**：OpenBLAS 0.3.x 系列对 ARMv8 (Cortex-A57/A72 等微架构) 有良好的支持，能自动检测并使用 NEON 指令集。这对于 CPU 端波束合成（矩阵乘法）至关重要。
|
||||
- **头文件**：`/usr/include/openblas/cblas.h` 已就绪，可直接使用标准 CBLAS 接口。
|
||||
- **探测依据**：
|
||||
|
||||
```bash
|
||||
ls -l /usr/lib64/libopenblas.so
|
||||
… libopenblas-r0.3.10.so
|
||||
```
|
||||
|
||||
**3. C++ 矩阵模板库 (Eigen3)**
|
||||
|
||||
- **关键性**：**P1**
|
||||
- **信息解析**：
|
||||
- **状态**：**Installed**。
|
||||
- **特性**：Eigen 是纯头文件库（Header-only），无需编译链接。它能自动检测并调用后端的 BLAS 库（如 OpenBLAS）进行加速，是现代 C++ 算法开发的首选。
|
||||
- **探测依据**：
|
||||
|
||||
```bash
|
||||
ls -d /usr/include/eigen3
|
||||
/usr/include/eigen3
|
||||
```
|
||||
@@ -0,0 +1,56 @@
|
||||
---
|
||||
tags: []
|
||||
date created: 星期三, 十一月 19日 2025, 8:16:48 晚上
|
||||
date modified: 星期三, 十一月 19日 2025, 8:17:14 晚上
|
||||
---
|
||||
|
||||
# 1.5.3 通信、存储与基础设施中间件 (Comm, Storage & Infra Middleware)
|
||||
|
||||
**审计综述**：
|
||||
Host 端数据基础设施已经补齐。我们确认 Protobuf 编译器已安装，可支持控制协议的开发；ZeroMQ 和 HDF5 库均已正确链接到系统库，数据传输和落盘能力已具备。
|
||||
|
||||
**1. 通信与协议中间件 (Comm & Protocols)**
|
||||
|
||||
- **关键性**：**P0**
|
||||
- **信息解析**：
|
||||
- **Protobuf 编译器**：`protoc` (v3.14.0) 已就绪。这使得开发者可以编译最新的 `.proto` 文件，用于控制指令或数据结构的版本化管理。
|
||||
- **ZeroMQ (ZMQ)**：库文件 `libzmq.so.2.4` 存在。这是构建雷达后端实时数据发布/订阅（Pub/Sub）消息总线的核心传输层。
|
||||
- **评估**：ZeroMQ (v5.x) 和 Protobuf (v3.x) 均为现代版本，Host 端具备高性能数据通信能力。
|
||||
- **探测依据**：
|
||||
|
||||
```bash
|
||||
protoc --version
|
||||
libprotoc 3.14.0
|
||||
ls -l /usr/lib64/libzmq.so*
|
||||
lrwxrwxrwx … /usr/lib64/libzmq.so -> libzmq.so.2.4
|
||||
```
|
||||
|
||||
**2. 数据存储中间件 (Storage Middleware)**
|
||||
|
||||
- **关键性**：**P0**
|
||||
- **信息解析**：
|
||||
- **HDF5 编译器**：`h5cc` 已就绪。`h5cc` 是 HDF5 库的专用编译器 Wrapper，它的存在证明 HDF5 的头文件和开发库已正确安装。
|
||||
- **用途**：HDF5 是存储雷达高维原始回波数据（IQ Data）的首选标准格式。
|
||||
- **探测依据**：
|
||||
|
||||
```bash
|
||||
which h5cc
|
||||
/usr/bin/h5cc
|
||||
ls -l /usr/include/hdf5.h
|
||||
-rw-r--r-- 1 root root 2561 … /usr/include/hdf5.h
|
||||
```
|
||||
|
||||
**3. 日志与配置设施 (Logging & Config Infra)**
|
||||
|
||||
- **关键性**：**P1**
|
||||
- **信息解析**：
|
||||
- **日志 (Glog)**：`libglog.so.0.0` 存在。Glog 提供了高性能的线程安全日志、VLOG 分级和断言机制，有助于雷达后端代码的稳定运行和故障排除。
|
||||
- **配置 (YAML)**：`libyaml-cpp.so.6.3` 存在。YAML 是比 JSON 更适合人工维护的配置文件格式，常用于存储复杂的雷达波位表或系统参数。
|
||||
- **探测依据**：
|
||||
|
||||
```bash
|
||||
ls -l /usr/lib64/libglog.so*
|
||||
… /usr/lib64/libglog.so.0.0
|
||||
ls -l /usr/lib64/libyaml-cpp.so*
|
||||
… /usr/lib64/libyaml-cpp.so.6.3
|
||||
```
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
tags: []
|
||||
aliases:
|
||||
- 1.6.1 异构调试与内存安全 (Heterogeneous Debugging & Memory Safety)
|
||||
date created: 星期三, 十一月 19日 2025, 8:31:15 晚上
|
||||
date modified: 星期三, 十一月 19日 2025, 8:31:38 晚上
|
||||
---
|
||||
|
||||
# 1.6.1 异构调试与内存安全 (Heterogeneous Debugging & Memory Safety)
|
||||
|
||||
**审计综述**：
|
||||
系统在调试层面具备极高的能力，Host 端 GDB 基础稳固，Device 端拥有专用调试器。然而，ASAN 库的安装路径不标准，需要手动配置系统链接器以启用。
|
||||
|
||||
**1. GDB 调试前端 (GDB Debugging Frontend)**
|
||||
|
||||
- **关键性**：**P0**
|
||||
- **信息解析**：
|
||||
- **版本与支持**：GDB 版本为 **9.2** (Kylin 定制版)，且 **Python 接口已激活**。
|
||||
- **价值**：Python 接口是 VSCode / CLion 等 IDE 实现高级断点、复杂结构体可视化以及 GDB 脚本扩展的必要条件。
|
||||
- **探测依据**：
|
||||
|
||||
```bash
|
||||
gdb --version
|
||||
GNU gdb (GDB) KylinOS 9.2-3…
|
||||
gdb -q -ex 'pi print(…)' -ex quit
|
||||
Python support is active
|
||||
```
|
||||
|
||||
**2. 异构调试工具链 (Heterogeneous Debugger Tools)**
|
||||
|
||||
- **关键性**：**P0**
|
||||
- **信息解析**：
|
||||
- **专用调试器**：**ixgdb** (Iluvatar GDB) 存在。这是用于 GPU Kernel 级断点调试的专用工具，等同于 NVIDIA 的 `cuda-gdb`。
|
||||
- **远程支持**：`gdbserver` 存在。可用于在远程开发机器（如 Windows/MacOS）上通过 VSCode/SSH 附件到 Kylin 服务器上的进程进行调试。
|
||||
- **探测依据**：
|
||||
|
||||
```bash
|
||||
ls -l /usr/local/corex/bin/*gdb*
|
||||
/usr/local/corex/bin/ixgdb
|
||||
/usr/local/corex/bin/gdbserver
|
||||
```
|
||||
|
||||
**3. 内存安全检测工具 (Memory Safety Checkers)**
|
||||
|
||||
- **关键性**：**P1**
|
||||
- **信息解析**：
|
||||
- **Valgrind**：**v3.13.0** 已安装，可用于 Host 端代码的内存泄漏和越界访问检测。
|
||||
- **ASAN (Address Sanitizer)**：库文件 `libasan.so` **已安装**在 GCC 7.3 的私有路径 (`/usr/lib/gcc/…`)。
|
||||
- **风险与修正**：ASAN 库默认对系统链接器不可见。已通过创建 `/etc/ld.so.conf.d/gcc7-asan.conf` 文件并执行 `ldconfig` 解决了此路径问题。
|
||||
- **探测依据**：
|
||||
|
||||
```bash
|
||||
which valgrind && valgrind --version
|
||||
/usr/bin/valgrind valgrind-3.13.0
|
||||
```
|
||||
@@ -0,0 +1,57 @@
|
||||
---
|
||||
tags: []
|
||||
date created: 星期三, 十一月 19日 2025, 8:34:02 晚上
|
||||
date modified: 星期三, 十一月 19日 2025, 8:34:18 晚上
|
||||
---
|
||||
|
||||
# 1.6.2 性能分析与实时监控 (Performance Analysis & Real-time Monitoring)
|
||||
|
||||
**审计综述**：
|
||||
系统在 Host 端和 Device 端均具备强大的性能监控和分析能力。已确认关键工具 `perf` 和 `ixprof` 存在，且内核支持完整的事件追踪。NUMA 内存分配均衡，为高性能雷达应用提供了可靠的诊断基础。
|
||||
|
||||
**1. GPU 性能分析工具链 (GPU Profiling Toolchain)**
|
||||
|
||||
- **关键性**：**P0**
|
||||
- **信息解析**：
|
||||
- **CUpti 接口**：`libcupti.so.2.89` 存在。**CUpti (CUDA Profiling Tools Interface)** 是所有高级 GPU 性能工具与驱动通信的底层接口，它的存在证明 GPU 侧的性能数据采集功能已激活。
|
||||
- **专用 Profiler**：`ixprof` (Iluvatar Profiler) 存在。这是用于采集 GPU 单元利用率、显存带宽和 Kernel 时序等指标的专用工具，可用于替代 `nvprof`。
|
||||
- **探测依据**：
|
||||
|
||||
```bash
|
||||
ls -l /usr/local/corex/lib/libcupti.so*
|
||||
… libcupti.so.2.89
|
||||
ls -l /usr/local/corex/bin/ixprof
|
||||
/usr/local/corex/bin/ixprof
|
||||
```
|
||||
|
||||
**2. Linux 内核级性能分析 (Kernel Performance Analysis)**
|
||||
|
||||
- **关键性**：**P0**
|
||||
- **信息解析**：
|
||||
- **Perf 工具**：`/usr/bin/perf` 存在。Perf 已识别出 **Bus Cycles**、**Cache Misses**、**CPU Cycles** 等 ARMv8 硬件性能计数器事件。
|
||||
- **内核追踪 (Ftrace)**：`/sys/kernel/debug/tracing/available_tracers` 文件存在（虽然大小为 0），证明 `debugfs` 已挂载，内核支持 **ftrace**。这为分析锁竞争、调度延迟等实时性问题提供了深度追踪能力。
|
||||
- **探测依据**：
|
||||
|
||||
```bash
|
||||
which perf && perf list
|
||||
/usr/bin/perf [Hardware events listed]
|
||||
ls -l /sys/kernel/debug/tracing/available_tracers
|
||||
… available_tracers
|
||||
```
|
||||
|
||||
**3. 实时系统与 NUMA 监控 (Real-time & NUMA Monitoring)**
|
||||
|
||||
- **关键性**：**P1**
|
||||
- **信息解析**：
|
||||
- **增强任务管理**：`htop` 已安装。这是比 `top` 更直观的实时任务管理器，有利于在运行雷达程序时实时观察 CPU 亲和性（Affinity）是否正确绑定在 Node 1 (CPU 16-31) 上。
|
||||
- **NUMA 内存分配**：`numastat -m` 显示 Node 0 和 Node 1 的物理内存总量和使用量**大致均衡**。当前没有明显的跨节点内存压力。
|
||||
- **默认策略**：`numactl --show` 显示当前 shell 默认策略是 `policy: default`，且绑定到所有 CPU (0-31) 和所有 Node (0/1)。
|
||||
- **重申风险**：这再次印证了为什么必须在启动 `main_app` 时使用 `numactl --cpunodebind=1 --membind=1` 强制覆盖默认策略。
|
||||
- **探测依据**：
|
||||
|
||||
```bash
|
||||
which htop
|
||||
/usr/bin/htop
|
||||
numactl --show
|
||||
policy: default
|
||||
```
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
tags: []
|
||||
date created: 星期三, 十一月 19日 2025, 8:38:01 晚上
|
||||
date modified: 星期三, 十一月 19日 2025, 8:40:07 晚上
|
||||
---
|
||||
|
||||
# 1.6.3 版本控制与数据基线管理 (Versioning & Data Baseline Management)
|
||||
|
||||
**审计综述**：
|
||||
系统具备稳固的版本控制基础，且已补齐了管理大型二进制文件所需的关键工具 **Git LFS**。Docker 的存在为构建标准化 CI/CD 流程提供了运行环境。
|
||||
|
||||
**1. Git 版本状态 (Git Version Status)**
|
||||
|
||||
- **关键性**：**P1**
|
||||
- **信息解析**：
|
||||
- **版本**：**Git 2.27.0**。该版本较为新近，支持所有现代 Git 功能（如稀疏检出、新版 Diff 算法）。
|
||||
- **平台**：运行于 `linux arm64`。
|
||||
- **探测依据**：
|
||||
|
||||
```bash
|
||||
git --version
|
||||
git version 2.27.0
|
||||
```
|
||||
|
||||
**2. 大文件存储支持 (Git LFS Support)**
|
||||
|
||||
- **关键性**：**P0**
|
||||
- **信息解析**：
|
||||
- **状态**：**Git LFS v2.10.0** 已安装，且已通过 `install --system` 进行全局初始化。
|
||||
- **价值**：解决了雷达项目管理大文件（如校准系数、模型权重）的痛点，确保 Git 仓库体积不会过度膨胀。
|
||||
- **探测依据**：
|
||||
|
||||
```bash
|
||||
which git-lfs && git lfs version
|
||||
/usr/bin/git-lfs
|
||||
git-lfs/2.10.0 (…)
|
||||
```
|
||||
|
||||
**3. CI/CD 环境工具 (Automation Tools)**
|
||||
|
||||
- **关键性**：**P1**
|
||||
- **信息解析**：
|
||||
- **容器化**：**Docker** 运行时已安装 (`/usr/bin/docker`)。
|
||||
- **价值**：这是将项目构建环境标准化（例如：将 GCC 7.3 和 Clang 18.1 封装在 Docker 镜像中）的关键，可确保 CI/CD 流程的构建结果具有高度可复现性。
|
||||
- **探测依据**：
|
||||
|
||||
```bash
|
||||
which docker
|
||||
/usr/bin/docker
|
||||
```
|
||||
Reference in New Issue
Block a user