On Thu, Jan 20, 2000 at 10:04:16AM -0500, Zhihui Zhang wrote:
> 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 ma
[EMAIL PROTECTED] (Arun Sharma) writes:
> 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 upfron
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 enter
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
> 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
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 w
6 matches
Mail list logo
