On Sat, Jun 21, 2008 at 4:35 PM, Javier Martín <[EMAIL PROTECTED]> wrote: > 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. > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > >
Or a set-grub-debug command that triggers grub to debug (load debug module) on next boot. If you're already going to hard code something. (you can set the next default boot so why not this) Looks very logical to me. You're only going (and want) to debug when something went wrong. (except devels) its also the most user friendly way. you can set that flag from grub or any OS. giving you info you need but normally don't want to see. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
