On Thu, Jul 31, 2008 at 7:22 PM, Robert Millan <[EMAIL PROTECTED]> wrote: > On Thu, Jul 31, 2008 at 03:46:47PM +0800, Bean wrote: >> diff --git a/include/grub/symbol.h b/include/grub/symbol.h >> index e951490..eef966f 100644 >> --- a/include/grub/symbol.h >> +++ b/include/grub/symbol.h >> @@ -43,4 +43,13 @@ >> # define EXPORT_VAR(x) x >> #endif /* ! GRUB_SYMBOL_GENERATOR */ >> >> +#define REAL_STUB_START(x) x ## _stub: ; \ >> + .long x ## _start ; \ >> + .long x ## _end - x ## _start ; \ >> +x ## _start: ; \ >> + .code16 >> + >> +#define REAL_STUB_END(x) .code32 ; \ >> +x ## _end: > > Shouldn't this be in an i386/pc/ subdir?
Oh, perhaps I can move them to include/i386/pc/kernel.h > >> + * On entry, %eax should points to a structure that specifies the code/data >> to >> + * be copied: >> + * >> + * offset 0: address of code/data >> + * offset 4: size of code/data >> + * >> + * grub_copy_real_stub fetches the address from offset 0, if it's not below >> 1M or >> + * properly aligned, it copies it to a reserved area and updates the >> address at >> + * offset 0, so that it don't need to do it again the next time. >> + * >> + * Currently, the reserved area for stub code/data is 0x80000 - 0x88000. It >> + * should be big enough for assembly code. > > I wonder if this could be made simpler. For example, by having a function > that just calls "int" in real mode. Then callers could use inline assembly > to put parameters in appropiate registers and reading results from appropiate > registers. Would this be faster than copiing hooks? INT sounds good, but it can't cover all cases. For example, it can't pass parameter using stack, or call a far pointer. Besides, we still need the stub area to store data. -- Bean _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
