On Monday 15 August 2005 04:29, Hollis Blanchard wrote: > Ruslan, I would ask for a different function name. Initially I was very > confused as to how/why GRUB was implementing mmap(2), but obviously > that's not really what's going on. Perhaps "grub_multiboot_get_memmap" > instead of "grub_multiboot_mmap"?
Good idea. > > The detection code should not be a part of the kernel. You can do this > > only > > protected mode, right? > > (I guess you mean the grub "kern" directory. Calling it "kernel" is a > little confusing because of course GRUB loads kernels...) > > Why shouldn't it go there? Where should it go? For the first question: because we do not need this function in the kernel. We should keep the kernel minimalistic, unless we have a good reason. For the second question: for now, it can be in the multiboot loader itself. If we find another use of this function, we can move it to somewhere else later (e.g. normal/i386/pc/misc.c or loader/i386/pc/helper.c). > > I prefer implementing this with inline assembly. > > That's quite a lot of inline assembly... why not make it its own > function? Because writing assembly should be avoided whenever possible. For example, you might want to test GRUB with a different calling convention (e.g. -regparm=0). If a function is written with inline assembly, the function entry code is automatically generated by GCC, so we do not have to modify it. If a function is written in assembly, we must modify it. This is critical when we want to use the same code for the native code and the emulator (grub-emu or grub-setup). Okuji _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
