The execBlock method supports the various control flows defined by the
ACPI standard (next instr, continue, break and return). It is designed
so that it can be recursively invoked both AML methods and various
flow-altering opcodes (e.g. opIf, opWhile e.t.c.)
Due to the large number of opcodes that the AML VM needs to support,
using a long switch statement will not be as performant as setting up a
jump table due to the way that the go compiler generates code for long
switch statements on integer values (asm code indicates that binary
search is used to select the switch target).
For the time being, the populateJumpTable method will assign a
placeholder function to each jump table entry that just returns a
"opcode X not implemented error".
This commit updates the post-parse step so that:
- the visitor not longer recurses into method bodies. Since code inside
methods may potentially generate dynamic/scoped entities or even use
conditional invocations (if CondRefOf(X) { X(...) }), symbol resolution
will be deferred to the AML interpreter.
- parent-child relationships between entities are checked and updated if
not properly specified
Since the ACPI standard allows forward function declarations this step
is required so we can properly parse the argument list for function
invocations. Contrary to other AML entities, method invocations do not
include any sort of pkgLength information so unless we track the
expected argument count for each function, our parser will not be able
to figure out where the argument list ends.
vmm.IdentityMapRegion can be used by device drivers that want to
establish an identity mapping for a contiguous physical memory block in
order to access some hardware or table.
The hal package automatically selects the best font from the list of
available fonts based on the console dimensions and the font priorities. The font
selection can be overriden by passing the "consoleFont" boot commandline
parameter to the kernel (e.g. consoleFont=terminus8x16)
Ths page offset is defined in arch/XXX/constants.inc and needs to be
passed to the kernel so we can correctly calculate the physical frame
addresses that correspond to the ELF section virtual memory addresses.
Currently, the kernel can write to 0xb80000 because this is part of the
initial identify mapping set up by the rt0 code. When we establish new
mappings for the kernel using its real VMA address then writes to the
framebuffer will cause a page fault unless we explicitly map it.
