Problem
rockusb write-bmap <IMAGE> currently decompresses images on the fly only for gzip (.gz); any other extension is treated as raw. That means a zstd-compressed image (.zst) has to be manually decompressed to a temporary file before it can be flashed, which wastes disk space and time for large images.
zstd is a common compression choice for OS/rootfs images (good ratio and fast decompression), so supporting .zst directly in write-bmap would be convenient.
Proposal
Add a .zst arm to write-bmap mirroring the existing gzip handling, for both backends:
- sync (libusb) path via
zstd::stream::read::Decoder
- async (nusb) path via
async_compression's ZstdDecoder
Care is needed so multi-frame .zst streams (e.g. produced by pzstd) are fully decoded rather than truncated after the first frame.
Fix
Addressed by #64.
Problem
rockusb write-bmap <IMAGE>currently decompresses images on the fly only for gzip (.gz); any other extension is treated as raw. That means a zstd-compressed image (.zst) has to be manually decompressed to a temporary file before it can be flashed, which wastes disk space and time for large images.zstd is a common compression choice for OS/rootfs images (good ratio and fast decompression), so supporting
.zstdirectly inwrite-bmapwould be convenient.Proposal
Add a
.zstarm towrite-bmapmirroring the existing gzip handling, for both backends:zstd::stream::read::Decoderasync_compression'sZstdDecoderCare is needed so multi-frame
.zststreams (e.g. produced bypzstd) are fully decoded rather than truncated after the first frame.Fix
Addressed by #64.