On Tue, Apr 10, 2012 at 8:43 PM, Tarl Neustaedter tarl-b2@tarl.net wrote:
On 2012-Apr-10 13:41 , Blue Swirl wrote:
Yes, but again, image size savings are not very interesting. Savings in image loading time is easily lost during decompression.
Why do you think image size saving aren't interesting? Certainly in the past couple of decades of Openboot development, we've several times been severely squeezed by prom sizes - in some cases, we had to rip out functionality to be able to fit in our PROM.
The problem is currently OpenBIOS won't work on a bare metal, since it's tightly coupled with qemu. So, PROM size at this point is a purely academical question.
For what it's worth, Openboot currently compresses the "dropin" images (FCode standalone images for devices) before assembling them into the PROM image, and decompresses those when they are brought in with find-dropin.
So, basically, if OpenBIOS has to support FCode "dropin" images, it must support the compression type (s?) used in OBP?