On 19.12.2011, at 23:01, Anthony Liguori wrote: > On 12/19/2011 11:35 AM, Alexander Graf wrote: >> >> On 24.07.2011, at 17:55, Göran Weinholt wrote: >> >>> Multiboot images can specify a bss segment. The boot loader must clear >>> the memory of the bss and ensure that no modules or structures are >>> allocated inside it. Several fields are provided in the Multiboot >>> header that were previously not used properly. The header is now used >>> to determine how much data should be read from the image and how much >>> memory should be reserved to the bss segment. >> >> This patch breaks the OSX booter: >> >> http://people.exactcode.de/~rene/mac/boot > > How is this licensed? Is there source available?
Yes, it's the XNU booter, but binaries are easier to debug when it comes to reading out the bootloader info: http://tgwbd.org/darwin/boot.html I don't know if the binary above is 1:1 built from those sources, but it's definitely close enough. > >> >> It now fails in fread(). Please revert this change for 1.0.1 and/or provide >> a timely fix. > > Is the patch incorrect in some way? I don't see how it's reasonable to > expect someone to fix a guest that cannot be legally run under QEMU. The guest is the bootloader which is an open source multiboot binary. The fact that it bootstraps OSX is a detail. It's a kernel that worked with -kernel before and is now broken. It also works with grub. I'd go as far as guessing that there are more kernels experiencing the same breakage. > If the patch is obviously incorrect, I'm all for reverting it, but I don't > think we can reasonably ask people to debug OS X guest failures since OS X is > clearly not allowed to run under QEMU. I think we can reasonably argue that multiboot kernels (especially the one kernel this whole thing was written for) that worked before shouldn't be broken, as that's clearly a regression. And usually regressions warrant reverts IMHO. But either way, I'd rather have this fixed. And once I'm through my pile of other patches to review and commit I'll gladly take a look at it. Until then, I'd rather have a 1.0.1 that works with what worked before, so behaves the same as 0.15 rather than a version that regresses. Alex
