--NextPart-20040325005502-0092200
Content-Type: Text/Plain; charset=us-ascii

[replying to the a little old mail]

> > I suspect that current behavoiur has become
> > 'de facto' so there is a possibility to break something with the
> > change.
> 
> yes.  it's why i mailed. :)

after grep'ing through syssrc and reading the result,
i'd say there're few instances that depend on the behaviour.
only place i've noticed to depend on it is in ubc_init,
which doesn't likely fail.
i'd commit the attached diff if no one object.

YAMAMOTO Takashi

--NextPart-20040325005502-0092200
Content-Type: Text/Plain; charset=us-ascii
Content-Disposition: attachment; filename="uvm.findspace.align.diff"

Index: uvm_bio.c
===================================================================
--- uvm_bio.c	(revision 641)
+++ uvm_bio.c	(working copy)
@@ -208,7 +208,11 @@ ubc_init(void)
 		    ubc_nwins << ubc_winshift, &ubc_object.uobj, 0, (vsize_t)va,
 		    UVM_MAPFLAG(UVM_PROT_ALL, UVM_PROT_ALL, UVM_INH_NONE,
 				UVM_ADV_RANDOM, UVM_FLAG_NOMERGE)) != 0) {
-		panic("ubc_init: failed to map ubc_object");
+		if (uvm_map(kernel_map, (vaddr_t *)&ubc_object.kva,
+		    ubc_nwins << ubc_winshift, &ubc_object.uobj, 0, 0,
+		    UVM_MAPFLAG(UVM_PROT_ALL, UVM_PROT_ALL, UVM_INH_NONE,
+				UVM_ADV_RANDOM, UVM_FLAG_NOMERGE)) != 0)
+			panic("ubc_init: failed to map ubc_object");
 	}
 	UVMHIST_INIT(ubchist, 300);
 }
Index: uvm_map.c
===================================================================
--- uvm_map.c	(revision 641)
+++ uvm_map.c	(working copy)
@@ -1651,13 +1651,11 @@ nextgap:
  wraparound:
 	UVMHIST_LOG(maphist, "<- failed (wrap around)", 0,0,0,0);
 
+	return (NULL);
+
  notfound:
-	if (align != 0) {
-		UVMHIST_LOG(maphist, "calling recursively, no align",
-		    0,0,0,0);
-		return (uvm_map_findspace(map, orig_hint,
-		    length, result, uobj, uoffset, 0, flags));
-	}
+	UVMHIST_LOG(maphist, "<- failed (notfound)", 0,0,0,0);
+
 	return (NULL);
 }
 

--NextPart-20040325005502-0092200--