On Fri, Jul 18, 2008 at 11:20 PM, Pavel Roskin <[EMAIL PROTECTED]> wrote: > On Fri, 2008-07-18 at 17:14 +0300, [EMAIL PROTECTED] wrote: > >> I think that using grub-emu might be a good idea for testing. I think >> there should be grub-emu architecture that could be compiled and in >> example there would be grub-emu specific disk layer, input layer and >> so on. So we could use grub-emu almost as same way we can do in real >> runtime environment. I know Marco will be using grub-emu like this on >> his GSoC project and I think it is a good thing too. But it needs some >> work of course. > > Yes, that would be a different grub-emu. Maybe it will be compiled with > the target flags. Maybe it will need to be disabled if cross-compiling. > >> We could do some special testing framework using this method. Eg. we >> could drive user input from special user input module that can be >> controlled from outside. > > I'd rather use qemu for testing, as it emulated the whole system. > Anyway, we'll see. > >> So please, do not at least remove support for using 64bit modules on >> 64bit systems :) (or otherwise make it harder to be supported later >> on) > > OK, let's keep it. I just don't want to force loading foreign > architecture modules into the executable memory.
Hi, Actually, GRUB_CPU_SIZEOF_VOID_P is the right one to use. It would only cause problem in grub-mkimage, but kern/dl.c is not used by grub-mkimage. -- Bean _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
