core: 按环境权衡 rom/RAM 取舍决定内核存储形态

[ashi009]

For #1304

问题

内核存哪种形态、放哪里，现在只看压缩包大小，没按设备环境权衡 rom 与 RAM 的取舍。以约 40M 的核心为例，几种形态的大致成本：

形态	rom 占用	RAM 占用（tmp=tmpfs）
gz（解压到 tmp）	10M	~40M（tmpfs，不可回收）
upx（memfd 执行）	9M	~40M+（memfd 就是 RAM）
裸二进制 / 压缩 fs	~15M	0（file-backed 可回收）
裸二进制 / 非压缩 fs	~40M	0

OpenWrt 上 $TMPDIR 是 tmpfs（RAM），rom 多为 squashfs/ubifs（透明压缩）。此时 upx 反而最费 RAM（stub 在 exec 时 memfd_create 把整个程序解压回内存），而 upx 却被当作小设备的首选格式（general_init.sh 里非 upx 才需把 /tmp 撑到 45M）。512MB 的 ipq60xx 上 MemAvailable 因此只剩约 40M。

改动

按环境计算偏好，而非写死某种格式。新增 store_raw_worth_it()：当 $TMPDIR 在内存（tmpfs）且 $BINDIR 能容纳裸二进制（按 fs 估算落盘体积——压缩 fs 约 2:1，否则全量——并预留余量）时，才把裸二进制存于 rom。

• rom 装得下裸二进制 → 存 $BINDIR/CrashCore.raw、$TMPDIR/CrashCore 软链、丢压缩包。rom 上被透明压缩，运行时 file-backed 可回收（RssShmem 归零）。压缩 fs 上裸二进制约 15M，几乎总是划算；非压缩 fs 上仅当 rom 有余量才选。
• rom 逼迫 / tmp 非内存 → 维持现状（rom 留压缩件，解压到 tmp）。rom 稀缺时压缩形态更优。

core_webget 也据此在裸存可行时跳过 upx 核心、改取 tar.gz（拿到裸二进制）。.raw 只是落盘形态不是下载格式；core_find 的 CrashCore.* glob 配合 core_unzip 新增的 .raw 分支在启动时重建软链。用户显式指定的 upx / 自定义链接维持原行为。顺带修正 upx 分支软链目标 $TMPDIR→$BINDIR（与 #1295 同一处悬空 bug）。

效果（ipq60xx, ImmortalWrt 25.12）

                改动前          改动后
MemAvailable    39900 kB        75724 kB
Shmem           45128 kB          980 kB
RssShmem        36876 kB            0 kB
RssFile           176 kB        36096 kB
/tmp 占用        45.1 MB          2.0 MB

验证

在真实 fs（$BINDIR 于 overlay/ubifs、$TMPDIR 于 tmpfs）上跑通：

• rom 有余量：store_raw_worth_it 成立（实测 20.1 余量 12M、10.1 余量 31M，均 > 8M）→ 存 CrashCore.raw、软链、可执行。
• rom 逼迫（调大余量阈值模拟）→ 回退存 CrashCore.gz、解压到 tmp。
• tmp 非内存（df 伪装 ext4）→ 不裸存（裸存不省 RAM）。
• config zip_type=upx + 裸存可行：默认核心下载被覆盖为 tar.gz → 存 raw。
• 自定义 .upx 为裸二进制：软链到 rom、运行时 RssShmem=0。
• 重启：core_find 重建软链指向 $BINDIR。

fs 估算比例（2:1）与余量阈值（8M）为保守默认，可调。

[ashi009]

请问下个 dev 版本大概什么时候发布？