Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 Jan 2000 10:04:16 -0500 (EST)
From:      Zhihui Zhang <zzhang@cs.binghamton.edu>
To:        adsharma@sharmas.dhs.org
Cc:        hackers@freebsd.org, Luoqi Chen <luoqi@watermarkgroup.com>
Subject:   Re: Accessing user data from kernel
Message-ID:  <Pine.GSO.3.96.1000120095742.24022A-100000@sol.cs.binghamton.edu>
In-Reply-To: <200001200214.SAA17214@c62443-a.frmt1.sfba.home.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On Wed, 19 Jan 2000, Arun Sharma wrote:

> In muc.lists.freebsd.hackers, you wrote:
> > 
> > When the kernel wants to access any user data, it either copies them into
> > the kernel or maps them into kernel address space.  Can anyone tell me the
> > reasons why this is done?  When a process enters the kernel mode, the
> > page tables are not changed. 
> > 
> > I have taken this for granted for a long time without knowing the reasons.
> 
> 1. The kernel may be entered asynchronously - from interrupts and traps.
>    You can't always be sure of which is the currently running user process.
> 
> 2. For cases where you've entered the kernel synchronously - through syscalls
>    for example, you need to check for the validity of data. You could 
>    potentially skip the step and validate the data where it is used, rather
>    than doing it upfront - but that may mean too many checks. It's just
>    cleaner to copyin/copyout once at entry/exit, rather than repeating the
>    code all over the place.

Thanks for your reply.  But I am still lost.

Point 1 seems to make sense. If the user data is already copied into the
kernel, we can access it just at any time, i.e., asynchronously. 

Point 2 seems to be saying that we would rather sacrifice some performance
to gain a cleaner interface (people are talking about eliminating kernel
copying for a long time). Consider the physical I/O on a raw device, where
we map the user data again in the KVA without copying the data. Why do we
do this double mapping, when we can access the user data directly?

-Zhihui




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.3.96.1000120095742.24022A-100000>