Subject: Re: Processes with multiple segments
To: Martin Girard <acheon@linuxmail.org>
From: Matt Thomas <matt@3am-software.com>
List: port-powerpc
Date: 10/03/2001 08:17:30
At 03:18 AM 10/3/2001 +0800, Martin Girard wrote:
>Hi,
>
>I found out something strange investigating whether a process could use 
>multiple segments on the ppc with NetBSD 1.5.1. In trap.c, the copyin() 
>and copyout() routines allow to copy kernelspace <==> userspace and allow 
>a process to use multiple segments by using as many bcopy()'s as necessary 
>and modifying the segment register of the user process in between.

All processes use multiple segments.  The user executable is in segment 0, 
the stack in segment 7, and shared libs are in segment 2 (or 4).

>However, in trap(), a process is assumed to be in userspace if the DAR's 
>segment is USER_SR (13). Worse, than that, the only other fixed segment 
>register is KERNEL_SR... (14, immediately after). Unless I miss something, 
>the trap mechanism assumes a userspace process can only use one segment ; 
>since in user mode one cannot change the segment register value, the only 
>way to use multiple segments is to use multiple segment registers.

Yep, you miss something.  The kernel VA space and the VA space are 
completely independent.  Usually, the kernel has no access to the user's 
address space.  USER_SR is used to grant the kernel temporary access to 
part of the user's address space.  When data at a user's address need to 
xfered from/to the kernel, the segment register of the segment containing 
that address is placed in segment register USER_SR.

>For now my hypothesis is that the implementation, for some obscure reason, 
>is only partial. But I'd like to know if it's really the case and if the 
>obvious workaround I just mentioned above would be compatible with the 
>rest of memory management as currently implemented.

Your hypothesis is faulty.
--
Matt Thomas               Internet:   matt@3am-software.com
3am Software Foundry      WWW URL:    http://www.3am-software.com/bio/matt/
Cupertino, CA             Disclaimer: I avow all knowledge of this message