Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!husc6!seismo!decuac!cvl!mimsy!chris
From: chris@mimsy.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: copyin (4.3BSD)
Message-ID: <5750@mimsy.UUCP>
Date: Tue, 10-Mar-87 13:12:59 EST
Article-I.D.: mimsy.5750
Posted: Tue Mar 10 13:12:59 1987
Date-Received: Thu, 12-Mar-87 23:38:04 EST
References: <4838@brl-adm.ARPA>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 26

In article <4838@brl-adm.ARPA> Conley%csvax.cs.ukans.edu@RELAY.CS.NET writes:
>Well, a couple of us here have been mucking with a system call ...
>one parameter is a string, and we use uap->string just like any other string
>(e.g. in a tprintf). However, an associate insists that this cannot be
>done, i.e. the string exists in user space (and this is kernel mode, hence
>kernel address space).

He is right.  However, user space and kernel space are not mutually
exclusive, not on a Vax.  Kernel code can look in user space if it
wants to.  If, however, the `string' is a wild pointer, the machine
will crash:

	main()
	{
		new_syscall((char *) 0xc0000000);
		/* NOTREACHED */
	}

>"Gotta do a copyin".

Not necessarily.  The routine for dealing with C strings in user
space is `copyinstr', but some other part of the kernel may be
doing that already (e.g., namei).
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP:	seismo!mimsy!chris	ARPA/CSNet:	chris@mimsy.umd.edu