xmd(4) (Re: XIP)

[Masao Uebayashi <uebayasi%tombi.co.jp@localhost>]

Here's the reason why I've written xmd_machdep.c:

xmd(4) is a read-only RAM-based disk driver capable of XIP.  The
main purpose is to test XIP functionality.  xmd(4) can be implemented
on any platforms that supports VM in theory.  xmd(4) may be also
useful for other cases where md(4) is used, but users want to save
memory.  md(4) allocates memory for its storage, and copies pages
from or to page cache.

xmd(4) allocates a static, read-only array and provides it as a
backing store.  When it's used as XIP, it registers the array as
a physical device page segment.  From VM's POV, the registered
region is seen like a ROM in a device connected over some buses.

The procedure to register an array as a physical segment is somewhat
strange.  The registered array resides in kernel's read-only data
section.  Kernel already maps its static region (text, rodata,
data, bss, ...) at boot time.  xmd(4) "re-defines" part of it as
a physical device segment, like a ROM connected via another bus.

As far as the backing store array resides in main memory, you'll
end up with some way to convert kernel VA back to physical address.
There is no alternative to achieve the goal in MI way, or xmd.c is
sprinkled like mem.c.

Masao