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
