sisong / hpatchlite Goto Github PK

First of all- amazing job and thank you for making this!

For context, I have been using jojodiff with JanPatch to create embedded binary OTA patch updates. I have ran a script across a large variety of firmware releases and on average, the tuz diff size is general 1/2 the size of the jojodiff. And even for very divergent binaries, the diff is still ~30KB less. And on top of that, it runs much faster.

The main reason I found this was to find a non-GPL diff library, since I want to port the diff generation code to golang without GPL restriction.

1. As far as I can tell, the other compression algos supported by hdiffpatch don't offer that much better compression (and proven by your comparison chart). I would suggest adding jojodiff to the comparison chart.

2. It seems like tuz-2k - tuz-5k both generate a pretty good diff, beyond that the diffsize vs. ram tradeoff isn't very enticing. It seems like for embedded applications, tuz is best. On the one hand, it would ideal to be able to just add hpatchlite as a submodule and define implementation methods, but in the current repo structure you have to pull in sources from hdiffpatch, hdiffpatchlite, and tinyuz. In comparison to janpatch this is a very tedious process for embedded developers. It would be nice to have 1-2 header files. This would probably help adoption, if that's important to you.

3. On smaller embedded devices running a bare-minimum OS, if any, POSIX apis are non-existent, overkill, or require special consideration. I got hdiffpatch working using something like this bdfile.h wrapper that provides POSIX-style API for a regular SPI Flash chip. However, it's a little confusing in the example what is _do_readOld vs _do_readFile in the example program. For embedded, we may need to have different implementations of _do_readFile- e.g. for old file data we want to read the currently running program flash, and for patch/new file we want to read/write to external SPI flash chip. I have implemented this in bdfile.h, but it would be helpful to have more documentation on what each stub is used for.

4. Kinda similar to 3, but for embedded we often don't want to pull in anything from stdlib. Is malloc even necessary? There are #ifdefs for not using errno, etc, but it would be nice to have a single config file. Also, it would be nice to make it so that assert is compiled in but simply returns an error so the the patch method can safely exit. Although it seems the asserts are more for debugging and shouldn't trigger on bad inputs?

5. Would also be nice to have the option to not use filenames and instead have an enum for old/diff/new. For non-posix filenames and directories are also unnecessary. As well as open modes ("rb", "w+", etc).

6. Consider using a code formatter like uncrustify.

In summary, the code works well and didn't actually need many tweaks for non-POSIX, but with a little re-organizing it could be made a lot easier to integrate for embedded.

$ cd

但是，当打开HPatchLite.sln，出现如下错误提示等：

错误 C1083 无法打开源文件: “....\HDiffPatch\libParallel\parallel_import.cpp”: No such file or directory

实际上，HDiffPatch是个空目录。

使用其它方式下载工程文件，同样存在如上错误提示。

这个HPatchLite支持流式差分更新吗?支持原地更新吗？

打补丁使用的库api 接口 hpatch_lite_open/hpi_BOOL hpatch_lite_patch，需要调用fopen/fread操作。但是不少单片机裸机系统上不支持fopen/fread，所以就不能使用当前现有的库接口来在单片即上实现patch功能。
如果能提供不依赖fopen/fread的API接口，比如当这些API patch接口的入参数据已经是读取文件之后的数据，库接口就更具有通用性，就方便在单片机上进行移植调用了。

On some systems, e.g. FreeRTOS, it is advised to not spend too long in a loop without occasionally yielding for other tasks to run. It would be nice to have some sort of progress indicator or optional callback stub to allow the user to yield during long loops. You could use the read/write stubs to see progress but it seems that execution time varies a lot between each coverCount. This might be more specific to tuz than hdiffpatch though.