Path: utzoo!attcan!uunet!cs.utexas.edu!swrinde!emory!mephisto!udel!mmdf
From: root@minixug.hobby.nl (The Master)
Newsgroups: comp.os.minix
Subject: (none)
Message-ID: <21905@nigel.udel.EDU>
Date: 13 Jun 90 17:58:47 GMT
Sender: mmdf@udel.EDU
Lines: 40

Subject: Re: mem_copy problem in MM
Newsgroups: comp.os.minix
References: <1990Jun6.154424.29594@mozart.amd.com>

From article <1990Jun6.154424.29594@mozart.amd.com>, by tim@proton.amd.com (Tim Olson):
> In article <21184@nigel.udel.EDU> HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes:
> | The user program gives an address in his own address space, this must
> | be converted to the flat space before using the address.
> | On the ST, this might go since all processes share the same address space
> | in reality, but you must not write code like that!
> | 
> | Second: I don't know if MM is allowed to copy something outside its own address
> | space (or if it uses the SYSTASK to perform such actions).
> 
> Both of these points are correct -- however, the person asking the
> question was using the mem_copy function, (in mm/utility.c), which
> does send a message to the kernel to perform the operation, and the
> kernel code does perform the virtual -> physical translation (via
> umap()) before performing the physical copy.
> 
> I think the real problem lies in correctly adding this new system call
> to mm's table.
> 
> 	-- Tim Olson
> 	Advanced Micro Devices
> 	(tim@amd.com)

Tim,

Thanks for the warning.
I indeed screwed up the system call order.  This probably happened
because I merged two calls ("A" and "B" into a new one, with name
"B".  I forgot to remove "A" from <minix/callnr.h> and to renumer
"B" in the same file...

The call works perfect now.  Since it is of general interest (it
is an implementation of the uname(2) call), I will post it next
weekend.

Fred van Kempen