From: Kevin Wolf <kwolf@redhat.com>
To: "François Revol" <revol@free.fr>
Cc: rene@exactcode.de, agraf@suse.de, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 0/4] Add multiboot support (x86) v2
Date: Thu, 18 Jun 2009 14:29:51 +0200 [thread overview]
Message-ID: <4A3A333F.40505@redhat.com> (raw)
In-Reply-To: <2966333961-BeMail@laptop>
François Revol schrieb:
>> François Revol schrieb:
>>>> Why would an OS want to parse multiboot structures but not
>>>> implement
>>>> proper multiboot support? I mean, this really isn't anything
>>>> complicated. When you have enabled it to understand multiboot
>>>> structures
>>>> you are only missing a handful of bytes for the multiboot header.
>>>>
>>>> What is it that you need to do differently for Haiku?
>>> Because Haiku has its own second stage loader, which requires the
>>> BIOS
>>> to locate the kernel and module in a BFS partition which grub
>>> doesn't
>>> implement btw.
>> That makes sense on real hardware, of course. But for -kernel you
>> don't
>> need a file system to read the kernel from.
>
> Except that wouldn't be the actual kernel passed but the 2nd stage.
> And having to pass the kernel in a tgz outside the BFS image makes it
> more complex to set up.
As Alex said, you don't need the tgz. Multiboot supports passing modules
to the kernel (or 2nd stage loader), i.e. files that are loaded into
memory by the bootloader (qemu in this case).
>>> It also handles PM switching by itself.
>>> Haiku might also use the BIOS for other stuff, like VESA mode
>>> switching, so I'd need to make sure all calls aren't strictly
>>> required.
>> In theory you could switch back to Real Mode when starting through
>> multiboot and then continue as with a normal boot. Admittedly,
>> doesn't
>> sound exactly nice, but should be doable...
>
> The loader can likey detect it anyway. If multiboot is used it should't
> need to call the BIOS to read the kernel anyway. It's just a different
> code path.
Detecting shouldn't be problem, you have the multiboot magic in eax. I
thought you would need the BIOS anyway (e.g. for VESA, as you mentioned
yourself). If you don't or you can use VM86 instead, it's going to be
much simpler, of course.
Kevin
next prev parent reply other threads:[~2009-06-18 12:31 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-17 16:41 [Qemu-devel] [PATCH 0/4] Add multiboot support (x86) v2 Alexander Graf
2009-06-17 16:41 ` [Qemu-devel] [PATCH 1/4] Change bochs bios init order Alexander Graf
2009-06-17 16:41 ` [Qemu-devel] [PATCH 2/4] Expose fw_cfg v2 Alexander Graf
2009-06-17 16:41 ` [Qemu-devel] [PATCH 3/4] Multiboot support v2 Alexander Graf
2009-06-17 16:41 ` [Qemu-devel] [PATCH 4/4] Multiboot build system Alexander Graf
2009-06-18 9:56 ` [Qemu-devel] [PATCH 3/4] Multiboot support v2 Avi Kivity
2009-06-18 10:22 ` Alexander Graf
2009-06-18 11:19 ` Avi Kivity
2009-06-17 17:10 ` [Qemu-devel] [PATCH 0/4] Add multiboot support (x86) v2 François Revol
2009-06-17 17:59 ` Anthony Liguori
2009-06-18 8:25 ` François Revol
2009-06-18 9:09 ` Kevin Wolf
2009-06-18 11:44 ` François Revol
2009-06-18 11:55 ` Alexander Graf
2009-06-18 12:13 ` François Revol
2009-06-18 12:01 ` Kevin Wolf
2009-06-18 12:17 ` François Revol
2009-06-18 12:23 ` Alexander Graf
2009-06-18 12:34 ` François Revol
2009-06-18 12:29 ` Kevin Wolf [this message]
2009-06-18 12:35 ` François Revol
2009-06-18 11:15 ` Gleb Natapov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A3A333F.40505@redhat.com \
--to=kwolf@redhat.com \
--cc=agraf@suse.de \
--cc=qemu-devel@nongnu.org \
--cc=rene@exactcode.de \
--cc=revol@free.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).