garrett_damore@tadpole.com wrote:

> I think this creates a bit of additional complexity.  Because the upper 
> layer only knows about the VA space assigned by the lower layer, it has 
> to allocate the extent on demand, and subdivide it.  And if you want to 
> map a larger chunk of data than fits in the remaining (upper) extent, 
> then the upper layer winds up having to allocate another extent based on 
> some new VA that the lower gives it.  (I guess it could do this by 
> creating a large extent over all space, allocating the whole then, then 
> selectively freeing space as the lower wired layer gives it mappings.)

Hmm, on arc port, whole VA range for each bus_space is mapped
in init functions, and bus_space_map function doesn't allocate
VA space. It just manage the VA range and doesn't care if the VA
is wired mapped or KSEG2 mappings.

But anyway I agree to keep MI functions simpler and
I could put the extent management in MD part.

> Btw, it would be pretty easy to take my work (with the latest split 
> EntryLo0 and EntryLo1 support), and call those functions from a more 
> "fully featured" wired map logic that did manage the VA address space on 
> its own.   I leave that as an exercise for the reader.

Heh ;-)

> You will note that I did not call my .c file wired_map.c, but rather 
> mips3_wired_map.c, in order to allow for the ARC specific wired_map 
> routines to coexist.

It's no problem to rename arc's wired_map.c to wired_map_machdep.c etc.
then MI file could be wired_map.c.

> + file	arch/mips/mips/mips3_wired_map.c	enable_mips3_wired_map & !mips1

!mips1 won't work properly because it can be specified with options MIPS3.
It should be 
"(mips3|mips4|mips32|mips64) & enable_mips3_wired_map" ?

> + #define	MIPS3_WIRED_PG_MASK	MIPS3_PG_SIZE_16M		/* 16 MB */

As I wrote before, this should be defined in MD header.
(i.e. this should be wrapped with #ifndef MIPS3_WIRED_PG_MASK/#endif etc.)
---
Izumi Tsutsui