From: Rene Rebe <rene@exactcode.de>
To: qemu-devel@nongnu.org
Cc: Alexander Graf <agraf@suse.de>
Subject: Re: [Qemu-devel] [PATCH] Add multi-boot kernel loading support
Date: Tue, 03 Feb 2009 09:15:37 +0100 [thread overview]
Message-ID: <4987FD29.3040404@exactcode.de> (raw)
In-Reply-To: <498776EC.1050208@codemonkey.ws>
Anthony Liguori wrote:
...
>> + memcpy(p, gdt, sizeof(gdt));
>> + p+=sizeof(gdt);
>> + *pgdt++ = gdtr;
>> + *pgdt++ = gdtr >> 8;
>> + *pgdt++ = gdtr >> 16;
>> + *pgdt++ = gdtr >> 24;
>> + }
>
> It was already pushing the limit to embed the linux loader. This is a
> bit too much. Perhaps we should split it to a separate .S file? I
> guess we could apply it as is but I'd like to see this code (along with
> the Linux code) moved to another file at least.
How do you want to assemble the .S file on non x86 builds, or just
ship a pre-built object like the BIOS?
>> + fprintf(stderr, "qemu: multiboot loader code is %d bytes
>> long.\n", (int)(p-rom));
>> +
>> + /* sign rom */
>> + sum = 0;
>> + for (i = 0; i < (sizeof(rom) - 1); i++)
>> + sum += rom[i];
>> + rom[sizeof(rom) - 1] = -sum;
>> +
>> + memcpy(option_rom, rom, sizeof(rom));
>
> This too could be common code.
Ok.
+ } else {
>> + /* Valid if mh_flags sets MULTIBOOT_HEADER_HAS_ADDR. */
>> + uint32_t mh_header_addr = ldl_p(header+i+12);
>> + mh_load_addr = ldl_p(header+i+16);
>
> Mixing variable definitions and code.
Yuck.
>> + fprintf(stderr, "multiboot: mh_header_addr = %#x\n",
>> mh_header_addr);
>> + fprintf(stderr, "multiboot: mh_load_addr = %#x\n",
>> mh_load_addr);
>> + fprintf(stderr, "multiboot: mh_load_end_addr = %#x\n",
>> mh_load_end_addr);
>> + fprintf(stderr, "multiboot: mh_bss_end_addr = %#x\n",
>> mh_bss_end_addr);
>
> It's a bit chatty by default.
Yes, indeed - though quite handy for a yet new feature. I could
just drop those (maybe after testing booting some other multi-boot
kernel as well, ...).
> Weird indent.
>
> What all uses multiboot at this point? I know Xen does.
Maybe other homebrew desktop kernels. I remeber there also
went support into NetBSD some time ago.
> Some additional documentation would be nice too.
Greetings,
Rene
--
René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
http://exactcode.de | http://t2-project.org | http://rene.rebe.name
next prev parent reply other threads:[~2009-02-03 8:15 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-02 18:08 [Qemu-devel] [PATCH] Add multi-boot kernel loading support Rene Rebe
2009-02-02 18:15 ` Nathan Froyd
2009-02-02 18:17 ` Alexander Graf
2009-02-02 18:25 ` Nathan Froyd
2009-02-02 22:42 ` Anthony Liguori
2009-02-03 8:15 ` Rene Rebe [this message]
2009-02-03 8:23 ` Alexander Graf
2009-02-03 8:27 ` Rene Rebe
2009-02-03 8:25 ` Alexander Graf
2009-02-03 8:29 ` Rene Rebe
2009-02-03 10:53 ` Jamie Lokier
2009-02-03 11:12 ` Alexander Graf
2009-02-03 12:58 ` Kevin Wolf
2009-02-03 13:57 ` Rene Rebe
2009-02-03 14:31 ` Kevin Wolf
2009-02-04 10:36 ` Rene Rebe
2009-02-04 13:05 ` Kevin Wolf
2009-02-03 13:01 ` Paul Brook
2009-02-03 14:00 ` Rene Rebe
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=4987FD29.3040404@exactcode.de \
--to=rene@exactcode.de \
--cc=agraf@suse.de \
--cc=qemu-devel@nongnu.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.