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 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).