[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] mmap support and x86_64 detection
From: |
Yoshinori K. Okuji |
Subject: |
Re: [PATCH] mmap support and x86_64 detection |
Date: |
Mon, 15 Aug 2005 10:29:21 +0200 |
User-agent: |
KMail/1.7.2 |
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