Thu, 02 Dec 1999 09:07:58 -0700
If you touch Linux code which works in real addressing mode
(initial setup, interrupts before VM is enabled, PDC/IODC) please
read 'Embedded Real-Mode Executable in vmlinux'
I have this working based on an old-ish set of code and
need to update it (maybe after the 2.3 merge). IF YOU HAVE OBJECTIONS
or QUESTIONS please raise them soon.
I have attached the plusses and minuses part of the document here,
but it may not make sense out of context (or in context either :-)).
* Code which runs in real mode is quite separate from code which runs in
virtual mode. One cannot by accident mix real/virtual code or data.
This should improve maintainability and reduce surprises.
* Real-mode code for setup, interrupt handling(*), and firmware
(PDC/IODC) access, may be written in C, with no suprise failures caused
by the whims of the C compiler and linker. This should improve
maintainability too, and using C should make this code more accessable
to non-assembly code wranglers.
(*)Nitpicker note: the interrupt vector table will still probably be
written in assembly, but the code it calls can be C.
* Certain interrupt handlers may be best implemented in real mode (TLB
miss?), and this provides an obvious place and method to do so (though
needed access to the kernel page tables may recommend a virtual-mode
TLB miss handler).
* It is probably possible to eliminate some of the currently duplicated
* The scheme is independent of the address at which we relocate vmlinux.
This is important since there are folks who want to relocate it to
0xC000-0000, 0x8000-0000, and 0x0001-0000.
* It's different. Today's kernel coders will not be familiar with this
* Much of the code available to the virtual kernel, such as printk,
memcpy, and other common functions, is not available in real land
unless it is copied. This may seem pretty bad, but we're already
copying code under our current scheme (e.g., real/vsprintf.c) because
of the limitations of PC-relative branches.
* The vmlinux file is larger, since the real-mode BSS segment is fully
expanded in realmode.S.
* More thought/design is required when writing code which has both real
and virtual portions. This is probably a benefit in disguise, but it
may cause frustration during the turn-on period.
* The convert program must be updated when we switch to ELF. Since the
boot loader and the implementation of exec() will need to do the same,
I don't consider this a big deal.
* Once we convert to the embedded executable scheme, it will be
inconvenient to go back, because it will entail small but widespread
changes. This could be mitigated by using a CVS branch (and tag)
* The compiler's millicode library is duplicated.