On Wed, Sep 26, 2012 at 05:34:25PM +0200, Marek Vasut wrote:
Dear Lei Wen,
On Thu, Sep 6, 2012 at 6:49 PM, Marek Vasut marex@denx.de wrote:
Dear Lukasz Majewski,
[...]
Ok, that means we can make use of this command ?
I cannot promise, that I will provide the "zip" support straightaway in the DFU.
On the one hand if DFU is the only user of this command we are adding in fact a "dead" code. On the other hand we can use proper #define CONFIG_CMD_ZIP to not compile it until we "really" use this.
I'd rather see a user and code added, not the other way.
common/cmd_zip.c is another user. :)
I'm OK with this one.
And file systems could use the zip callback to directly create the zipped file.
Definitelly not ... zip callback for FS is wrong.
Since current ext4 and fat in uboot support write function, I think it could be a potential feature to add.
cmd_zip + fs write call is OK. But why do we need to zip anything in uboot, what's the usecase?
Are there any other potential "users" of this functionality (ZIP compression/decompression) in u-boot?
None that I know of. Is it really zip or is it gzip ?
It is porting from zlib, and is there any different for the compression side for zip and gzip?
I ain't no expert, so I'm asking
This patch is pending for too long time, do we have a answer now whether it could be merged?
Ccing Tom
I am fine, conceptually. I see a few needed changes / clarifications: - Is this zip or gzip compression in the exposed command? - You don't update README with CONFIG_CMD_ZIP