eerimoq / detools

Binary delta encoding tools.
Other
159 stars 15 forks source link

Patch version info in metadata #10

Closed laukik-hase closed 1 year ago

laukik-hase commented 1 year ago

Hello, @eerimoq!

I am using detools for patching embedded firmware. Could we make a provision for storing the source firmware version (from which the patch was created) in the patch header/metadata and add an API for fetching the same in the C source?

Thanks a lot!

eerimoq commented 1 year ago

I implemented a first version in the Python code on the master branch. Please have a look and let me know what you think about it.

It's basically possibly to add a user defined blob of data to the patch header. The blob can contain anything.

❯ cat my-header.txt 
User defined blob.
❯ python3 -m detools create_patch --user-header-data my-header.txt tests/files/foo/old tests/files/foo/new patch
Successfully created 'patch' in 0.02 seconds!
❯ python3 -m detools apply_patch --user-header-data my-header-2.txt tests/files/foo/old patch new
Successfully created 'new' in 0 seconds!
❯ cat my-header-2.txt 
User defined blob.
❯ cmp my-header.txt my-header-2.txt 
❯ python3 -m detools patch_info patch                                                                           
Type:               sequential
Patch size:         149 bytes
To size:            2.71 KiB
Patch/to ratio:     5.4 % (lower is better)
Diff/extra ratio:   9828.6 % (higher is better)
Size/data ratio:    0.3 % (lower is better)
Compression:        lzma
User header data:
  00000000  55 73 65 72 20 64 65 66  69 6e 65 64 20 62 6c 6f  |User defined blo|
  00000010  62 2e 0a                                          |b..             |
Data format size:   0 bytes

Number of diffs:    2
Total diff size:    2.69 KiB
Average diff size:  1.34 KiB
Median diff size:   1.34 KiB

Number of extras:   2
Total extra size:   28 bytes
Average extra size: 14 bytes
Median extra size:  14 bytes
❯ xxd patch           
00000000: 8115 0113 5573 6572 2064 6566 696e 6564  ....User defined
00000010: 2062 6c6f 622e 0a9c 2b5d 0000 8000 ffff   blob...+]......
00000020: ffff ffff ffff 0000 2b2e 5904 6078 9cc6  ........+.Y.`x..
00000030: 6e56 024e ad20 3bd5 c2a1 7ae9 f9fd 2970  nV.N. ;...z...)p
00000040: 043c 2320 6841 cc8e 30b6 9389 810b 77f9  .<# hA..0.....w.
00000050: 011f f777 014e 275d ed92 fc12 4e86 5157  ...w.N']....N.QW
00000060: 6f45 2dfa d0e0 be5b 402c 1a90 aafd a008  oE-....[@,......
00000070: e1b6 3db5 cba7 537b 66b8 997a ebd6 b081  ..=...S{f..z....
00000080: 12c2 5a9a 6a66 0e58 f402 2f45 4b3a 1a1e  ..Z.jf.X../EK:..
00000090: 7ffc 620a db                             ..b..
eerimoq commented 1 year ago

I am not sure this is a good approach. Maybe easier to not add support for this, and instead it's up to the user to store metadata elsewhere according to her format.

Can you please give more details on your use case for a better understanding if this feature is "really" needed, or if it is easier to pass version information elsewhere?

laukik-hase commented 1 year ago

Yes, I understand. The patch does not need to store the source and destination firmware versions; we'll explore alternate solutions.

Closing the issue, thanks for your help!