Dear Wolfgang,
2013/7/26 Wolfgang Denk wd@denx.de:
Dear Guilherme Maciel Ferreira,
In message CAF=5bWcMhBhvvWP1933Xyi9Cpv_t3Y306ceWr6pH+TqwoYpi=g@mail.gmail.com you wrote:
But I fear that mkimage explodes from creaping featurism, so if you go and implement something like this, please do not add it to kmimage, but rather create a separate, new tool, say "dumpimage" or so.
How does 'unimage' sound to you? =) Following the example of unsquashfs and unubi?
I dislike such names; they appear not natural to me. "Make an image" => mkimage or "dump the image content" => dumpimage kind of describe what the command does in a natural language. But "unimage" is a word that I cannot put anywhere.
dumpimage... That's fine for me.
I mean, if people really consider this tool of some use.
The simple rule is: if something is useful for someone, and does not hurt others, it can get added. Just make sure it's a separate make target so it does not get built automatically for each and every build, but only when you ask for it.
Ok. Just give me some time to rework the patch.
However, now we want a selective upgrade, where we can pick a few directories from within the new root file system without the need to write the whole new file system and kernel.
Hm... Repacking images on the target appears not really an efficient approach to me. Also I wonder how this works - are you talking about ramdisk based root file system images?
Exactly, a ramdisk root file system image, which is received -- by the device -- inside a Multifile image.
Best regards,