Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!sun!pitstop!sundc!seismo!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: kernel questions
Message-ID: <1025@auspex.UUCP>
Date: 16 Feb 89 09:39:32 GMT
References: <885@ncr-sd.SanDiego.NCR.COM> <15948@mimsy.UUCP>
Reply-To: guy@auspex.UUCP (Guy Harris)
Distribution: usa
Organization: Auspex Systems, Santa Clara
Lines: 24

>>1) If a user process can be 'nailed' into memory, is there still a
>>need to copyin(k) data from user virtual address space into kernel
>>address space? If no, could the kernel then access the user data
>>in the user virtual address space with minimum overhead?
>
>A) no, and b) yes, and in fact this is what `raw I/O' does.

Well, sort of.  When doing "raw I/O" the kernel generally doesn't even
touch the data; it lets the I/O subsystem do so (which is why the
details are machine-dependent, as indicated).

If kernel code wants to access the data directly, that's *also*
machine-dependent; some systems provide separate address spaces for
kernel-mode and user-mode code (e.g.  a Sun-2), which means that
user-mode virtual address N and kernel-mode virtual address N refer to
different physical addresses, and there may not *be* a kernel-mode
virtual address that refers to the same physical address as user-mode
virtual address N. 

In addition, of course, the kernel may or may not want to access the
data directly; for instance, it may have write permission on some
location that the user does *not* have write permission on, and if it's
doing stuff on behalf of the user, it may not want to modify a location
for the user process if it can't modify it itself.