From owner-freebsd-hackers  Tue Jan 13 19:17:07 1998
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id TAA28459
          for hackers-outgoing; Tue, 13 Jan 1998 19:10:51 -0800 (PST)
          (envelope-from owner-freebsd-hackers@FreeBSD.ORG)
Received: from rah.star-gate.com ([209.133.7.178])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA21092;
          Tue, 13 Jan 1998 18:31:39 -0800 (PST)
          (envelope-from hasty@rah.star-gate.com)
Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1])
          by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id SAA01545;
          Tue, 13 Jan 1998 18:31:19 -0800 (PST)
          (envelope-from hasty@rah.star-gate.com)
Message-Id: <199801140231.SAA01545@rah.star-gate.com>
X-Mailer: exmh version 2.0gamma 1/27/96
To: Mike Smith <mike@smith.net.au>
cc: Stephen Hocking <shocking@mailbox.uq.edu.au>, multimedia@FreeBSD.ORG,
        hackers@FreeBSD.ORG
Subject: Re: FreeBSD Quake page 
In-reply-to: Your message of "Tue, 13 Jan 1998 11:56:31 +1030."
             <199801130126.LAA04334@word.smith.net.au> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 13 Jan 1998 18:31:19 -0800
From: Amancio Hasty <hasty@rah.star-gate.com>
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk

Still no joy over here with Quake ][ :(
These are the parameters  that Quake ][ is calling mremap with:
mremap error = 0 --  1 0 2 0 3 0 4 0 

All args are 0....

For this weird case, I am not even sure what to return. On a related
vein , I booted linux and noticed that Quake ][ does not call
mremap which probably means that something else is wrong with the linux
emulation layer.


	Amancio


> > 
> > syscall 163 is the linux system call mremap which we have not implemented.
> > 
> > If anyone knows how to implement mremap  please let me know.
> 
> Heh.  I finally managed to get a copy of the Linux kernel source where 
> I can look at it.  
> 
> mremap() is more or less what its name suggests; it allows you to 
> modify an existing mapping. 
> 
> u_long
> mremap(caddr_t addr, u_long old_len, u_long new_len, u_long flags)
> 
> There are basically two cases.
> 
>  - Shrink a mapping.  (new_len < old_len)  You can implement this as
>    munmap(addr + new_len, old_len - new_len).
> 
>  - Grow a mapping, moving disallowed.   This requires changing map 
>    details.  I *think* I can see, in principle, how to do this, but it
>    would have to be done in the vm_mmap module rather than in the 
>    linuxulator.
> 
> John, can you comment on this?
> 
> As a quick hack, you could try implementing the shrink case, and return 
> ENOMEM for the other cases.  This *might* work, depending on the 
> consumer.
> 
> -- 
> \\  Sometimes you're ahead,       \\  Mike Smith
> \\  sometimes you're behind.      \\  mike@smith.net.au
> \\  The race is long, and in the  \\  msmith@freebsd.org
> \\  end it's only with yourself.  \\ 
> 
>