[comp.os.minix] mem_copy problem in MM

root@nluug.nl (The Master) (06/06/90)

Hi!

I have a problem, and I don't know what I am doing wrong
here.  Thus, it is probably some very obvious error...

In MM, I have a structure of data, say:

PUBLIC struct testdata testdata;

Now, I add a system call with format m1, which has a
pointer to a similar structure in user space.  The
ptr is in m1_p1.

To copy the MM version of the data to the address in
user space, I can use the following code:

  vir_bytes src, dst;
  int len, r;

  /* Get the SRC and DST addresses right. */
  src = (vir_bytes) &testdada;
  dst = (vir_bytes) mm_in.m1_p1;
  len = sizeof(struct testdata);
  r = mem_copy(MM_PROC_NR, D, (long) src, who, D, (long) dst, (long) len);
  return(r);

Now, when I call this system call with the function:

#include <sys/types.h>
#include <fcntl.h>
#include <string.h>
#include <lib.h>


int testit(bufp)
struct testdata *bufp;
{
  int st;

  st = callm1(MM, TESTCALL, 0, 0, 0, bufp, NIL_PTR, NIL_PTR);
  return(st);
}

I get the result "-1", and perror() says "Invalid argument" .

Does anyone know what is going on here?  It is driving me up
the wall!

HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (06/06/90)

I think you are using 68K-MINIX, since there is a weak point:

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).

C.v.W.

tim@proton.amd.com (Tim Olson) (06/06/90)

In article <21169@nigel.udel.EDU> minixug!root@nluug.nl (The Master) writes:
| Now, I add a system call with format m1, which has a
| pointer to a similar structure in user space.  The
| ptr is in m1_p1.
|
| Now, when I call this system call with the function:
| I get the result "-1", and perror() says "Invalid argument" .

All of your code looks correct.  However, one possibility is that you
didn't correctly add the new system call number to the call_vec table
in table.c.  If it somehow still points to no_sys (the default for all
unimplemented call numbers), then you will end up at the no_sys
function in utility.c which (surprise!) returns EINVAL.

	-- Tim Olson
	Advanced Micro Devices
	(tim@amd.com)

tim@proton.amd.com (Tim Olson) (06/06/90)

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)

root@minixug.hobby.nl (The Master) (06/14/90)

From article <21184@nigel.udel.EDU>, by HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen):
> I think you are using 68K-MINIX, since there is a weak point:
No, MUG-MINIX 1.5.10C-PC

> 
> The user program gives an address in his own address space, this must
> be converted to the flat space before using the address.
Yeah, that is why "mem_copy" gets the 'who' parameter ???

> On the ST, this might go since all processes share the same address space
> in reality, but you must not write code like that!
Agreed, but tell this to some calls!
Sometimes, using this kind of code is to be preferred over marshalling
parameters into a single message, like the ioctl() system call does...

> 
> 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).
Not sure, I think it uses SYSTASK.  I will check on this later...

Fred.