Subject: Re: port-mips/31915: provide centralized wired_map logic
To: None <tsutsui@netbsd.org, gnats-admin@netbsd.org,>
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
List: netbsd-bugs
Date: 10/28/2005 13:52:02
The following reply was made to PR port-mips/31915; it has been noted by GNATS.

From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: garrett_damore@tadpole.com
Cc: gnats-bugs@NetBSD.org, port-mips@NetBSD.org,
	tsutsui@ceres.dti.ne.jp
Subject: Re: port-mips/31915: provide centralized wired_map logic
Date: Fri, 28 Oct 2005 22:51:26 +0900

 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