>From: jiho@postal.c-zone.net
>Well, hrmph....actually, I was looking to follow whatever might be going
>on and then see if I had additional questions.

what is going on?   well, the current status is that the code is in the
tree and the selection of VM system is a compile-time option.  porting
and bug report collecting is currently in progress (uvm currently runs ok
on alpha, hp300, i386, mvme68k, and vax).   i would expect thing to remain
moving at the current slow-but-steady pace for the next few months.



>Unfortunately, I wasn't able to get a kernel with it running.  I have a 
>1.2/i386 installation.  A 1.3 kernel built (by hand for my hardware) 
>with uvm refused to boot -- froze trying to run init, I think.
>My 1.2 kernel with uvm as a drop-in replacement never built successfully. 

i'm not clear on how you managed to compile a 1.3-release kernel with
uvm, but i can tell you that in order to have success with that sort 
of project you'd have to un-do the address-space sharing vfork-related
changes introduced in the tree around 1998/01/03.   if you want to play
with uvm, your best bet is to try and run a -current (1.3E) kernel.



>One thing I do know is that with the Mach vm system, shared libraries
>don't share code pages properly.  I've tested things pretty thoroughly, 
>and that conclusion sifts out consistently.  Code pages from core process 
>files are properly shared; those from shared library files are not.  You 
>are literally better off to run a completely statically linked system, 
>than to use any shared libraries (especially with X).  

hmm, well, i haven't observed anything along these lines.   if you look
at how both static and dynamic binaries are run you'll note that it all
goes through the same memory-mapping mechanism.  for the static part of
a demand-paged binary, we are routed through vmcmd_map_pagedvn() in
kern/exec_subr.c to vm_mmap().   for programs that use shared libs, 
ld.so uses mmap(2) to map the libs in.   the code path on that would
be sys_mmap() -> vm_mmap() [all in vm/vm_mmap.c].    so, both static
and dynamic code-related memory mappings boil down to vm_mmap() calls.
what sort of tests did you run when looking into this?
 
 
chuck