This removes again the single_page_map_offset configuration value,
and requires that a full/correct config be used to supply a manual DTB
value.
The expectation is that the single_page_map_offset feature be
re-introduced but override *all* scanning (so the scanning doesn't take
place even if the stacking does).
We shouldn't be stacking unless we're required, so now
we run after the construction phase, and run our own construction
phase is we've changed anything.
The physical layer will miss certain patterns, but is an order of
magnitude faster at scanning. The main amount of time spent in scanning
Intel spaces is counting through every page in the address space (32, 40
or 64 bits), not the actual scanning. There's no real way around this
if you want to ensure you get every chunk of virtual memory. Since the
scanner could be stopped after its first hit, this might still be
preferable, but should not be the default (particularly for an automagic
scan).
This change is quite signficant, and requires that TranslationLayers
get all additional parameters that they need through their requirements.
These are now automatically enumerated and populated on object
construction based on the requirements, so should not require lots of
repetitive filling out of fields.
It does come with the downside that TranslationLayers can only be
contructed with a context (and appropiate config), but TLs in particular
always require a context (to contain the base layer) and blank configs
can be constructed relatively easily (convenience functions can be added
if necessary).
This allows configuration trees to be built up, and their configs
spliced into an existing config (as if it were being loaded from a
file).
Not all ConstructableRequirements use this method, since SymbolTables
(for example) do not have access to the context or config_path in order
to get to any parameters stored in the context's config. They therefore
are still passed their requirement values as __init__ parameters
instead.
Mike Auty