fe58c46ead
The existing implementation would handle kernel differences just fine but a bit too automatically: if it sees xz support, that's what will end up being used (and if there's -Xbcj binary compression filter available for the target platform, it will be applied unequivocally either). It's perfectly suitabe for getting fine-tuned release images but is also a bit too resource-consuming while developing the image configuration which has no business with its compression. The one and only knob is SQUASHFS (see doc/variables.txt); to give an idea of the differences, here are some numbers for a mostly-binary (43% as per 99-elf-stats) webkiosk livecd and a rather less so (18%) flightgear one on a dual quad-core X5570 node (each mksquashfs run used up all the cores): SQUASHFS | live-webkiosk.iso | live-flightgear.iso ---------+-------------------+--------------------- fast | 3:30 / 130M | 5:11 / 852M normal * | 3:37 / 100M | 5:35 / 688M tight | 3:50 / 98M | 6:47 / 683M Thus if the knob isn't fiddled with, the defaults will allow for a reasonably fast build of a pretty slim image; if one is building a release or if a particular image is very sensitive being close to the media capacity then just add SQUASHFS=tight and see it a percent or two down on size. Please note that lzo/gzip-compressed images are also quicker to uncompress thus further helping with test iterations. Thanks to led@ and glebfm@ for helpful hints and questions. |
||
|---|---|---|
| .. | ||
| scripts.d | ||