Re: xmd(4) (Re: XIP)

[yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)]

hi,

> 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.

why can't you use pmap_extract?

YAMAMOTO Takashi

> 
> Masao