[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Using emap for i386/amd64 early during boot
On 21.06.2010 00:39, Mindaugas Rasiukevicius wrote:
Jean-Yves Migeon<jeanyves.migeon%free.fr@localhost> wrote:
I know that a lot of legacy code uses the preprocessor the way that you
have in i386_cpu_switch_pmap(), but I don't think that the preprocessor
should be used in that way any longer. In my experience, code that uses
the preprocessor heavily is harder to read and to change and to test.
Why don't you let config(1) and ld(1) do the work that the preprocessor
does? For example:
I like that. Will do. Thanks!
Agree with David's point, but it should not be done at function level.
Rather higher level interface abstraction. In uvmplock branch, I have
already split some x86 pmap bits into pmap_tlb.c and xen_pmap.c modules.
More interfaces can be abstracted in respect to e.g. Xen.
I just took a look: to avoid ugly #ifdef's, we have to handle 4
different scenarios for pmap switching:
- i386 native, amd64 native, and i386 Xen (no-PAE) case, which all share
the same piece of code (use of lcr3)
- i386 PAE, not Xen: iterate through L3 entries, without Xen address
physical => machine address translation
- i386 PAE, Xen: same as above, but use P2M translations
- amd64 Xen, where pmap code has some quirks to circumvent amd64
limitations regarding paravirtualization.
I can split Xen and non-Xen case, but we will still have to distinguish
i386 and amd64 case, as well as PAE/!PAE (within i386). Either we deal
with it at function level and let config(1) handle that, or cpp(1).
Choice is limited here :/
For your branch:
* xen/x86/xen_pmap.c will contain the code for i386 (PAE & !PAE), amd64,
only for Xen
* x86/x86/pmap.c will contain native i386 (PAE & !PAE), and amd64.
Is pmap.c expected to be split in two files too (pmap.c and x86_pmap.c?)
I noticed that in your pmap.c, some functions (already found in
xen_pmap.c) are "#ifndef XEN" out, to avoid conflict I suppose.
Main Index |
Thread Index |