From: "Javier Martín" <lordhabbit@gmail.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: [PATCH] add a counter in grub_dprintf
Date: Sat, 21 Jun 2008 16:35:07 +0200 [thread overview]
Message-ID: <1214058907.10018.39.camel@localhost> (raw)
In-Reply-To: <20080621141907.GC24465@thorin>
[-- Attachment #1: Type: text/plain, Size: 1422 bytes --]
El sáb, 21-06-2008 a las 16:19 +0200, Robert Millan escribió:
> But space in post-mbr area is precious, and if we can save a bit, it means
> less users who will run into trouble in first place.
>
Disclaimer: the following is just the product of brainstorming from a
mind tortured by hours of studying projective geometry. Use with care ^^
Why not modify the build system to create _two_ instances of kernel.img,
one with and another without debugging? grub_mkimage would create the
normal, smaller core.img (without dprintf) for installing and embedding;
and store a core_dbg.img in the /boot/grub folder, so that if
instrumentation is required the only thing the users needs to do is
chain that debug version of GRUB:
grub> multiboot /boot/grub/core_dbg.img
grub> boot
Another option would be to separate grub_dprintf into a module of its
own that could, or could not, go into core.img depending on space
pressure. We'd still need a "grub_dprintf" in the kernel, but it would
just reduce to "Is debug.mod loaded? Yes->call debug_grub_dprintf". This
would only result in a substantial reduction of kernel if grub_dprintf
is currently a big function (and I haven't even taken a look at it) with
format substitution and all. The downside is that we'd have no dprintf
at all until modules are loaded, though some logic can be hardcoded so
that debug.mod is loaded first, if present.
[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
next prev parent reply other threads:[~2008-06-21 14:34 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-19 13:31 [PATCH] add a counter in grub_dprintf Robert Millan
2008-06-19 18:42 ` Isaac Dupree
2008-06-21 14:19 ` Robert Millan
2008-06-21 14:35 ` Javier Martín [this message]
2008-06-21 14:51 ` Bram Diederik
2008-06-22 11:30 ` Isaac Dupree
2008-06-26 14:08 ` Robert Millan
2008-06-26 15:20 ` Javier Martín
2008-06-29 11:22 ` Robert Millan
2008-06-30 17:13 ` Pavel Roskin
2008-06-30 17:33 ` Vesa Jääskeläinen
2008-07-01 15:59 ` Robert Millan
2008-07-01 15:59 ` Robert Millan
2008-07-01 16:01 ` Pavel Roskin
2008-07-01 17:19 ` Robert Millan
2008-07-02 0:13 ` Pavel Roskin
2008-07-03 18:08 ` Marco Gerards
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=1214058907.10018.39.camel@localhost \
--to=lordhabbit@gmail.com \
--cc=grub-devel@gnu.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.