[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2] multiboot: Fix bss segment support

From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH v2] multiboot: Fix bss segment support
Date: Mon, 19 Dec 2011 23:26:08 +0100

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:


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:

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]