[Toybox] Going through Oliver's xz commit list...

[Rob Landley]

On 6/25/25 08:21, enh wrote:
> between https://android-review.googlesource.com/c/platform/external/xz-embedded/+/3032623
> and https://android-review.googlesource.com/c/platform/external/xz-embedded/+/3040077
> i ended up disabling this stuff on android. the bug link you can't
> follow on the first change has one of the OTA guys experimenting and
> finding that (a) there's no size decrease for an OTA package and (b)
> there's a 2% time cost.

Yeah, not surprising. That said, the decoder needs it to handle packages 
that _do_ contain it, as part of the expanded file format. Presumably 
only the compressor took a time hit, not the decompressor?

If I did a compressor, I wouldn't do the BCJ encoders.

> another OTA guy questioned whether the
> experiment had been done right, but given our assumption that this
> optimization is effectively done already for dynamic binaries
> (courtesy of the PLT) it didn't seem worth putting in further effort
> to try to prove any value to this, and all things being equal, less
> code is better.

Agreed, but an extractor that's being fed random third party tar.xz 
files probably still needs to handle the legacy formats.

> note that if you go in the other direction and do want this stuff,
> there's also a new risc-v implementation too.

Mostly I'm thinking of LFS/BLFS source tar.xz files which are unlikely 
to contain binaries. (My own embedded systems usually use gzip, not xz. 
Less runtime overhead.) But that's _my_ use case. There are people 
building little embedded systems with toybox who may have tar.xz files 
that do contain binaries made with random Linux distro du jour's 
encoder, so... (Kernel tarballs are distributed as .xz and I wouldn't be 
surprised if tools/testing grew reference binaries...)

If the encoder's got it, and might sometimes use it, the decoder would 
barf if it can't understand it.

Rob