Subject: Re: COPYIN/COPYOUT macro problems Re: IOCTL implementation and kernel/userland addresses
To: Gordon Waidhofer <gww@traakan.com>
From: Reinoud Zandijk <reinoud@netbsd.org>
List: tech-kern
Date: 08/25/2005 23:29:46
--dWYAkE0V1FpFQHQ3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Thu, Aug 25, 2005 at 02:14:46PM -0700, Gordon Waidhofer wrote:
> Don't take this too seriously. It's just thought food.
> 
> Some machine architectures have multiple address spaces.
> An easy example was the separate I&D (Instruction, Data)
> spaces on the PDP-11. The IBM EA architecture (don't know
> much about it) has multiple address spaces and an instruction
> set to allow "far" accesses.
> 
> On a VM project I worked on a long, long time ago, our version
> of copyin/out took a pointer to the address space being operated
> upon. Think of this as a pointer to the vm_map anchor. Familiar
> interfaces, uiomove() et al, were bandaided at the time, and let
> the EA guys figure out how to do it right.
> 
> This ioctl() question came up and I remembered all the long
> ago grapling.
> 
> The upshot is that it might be helpful to think of the address
> space selector a little more broadly than a kernel/user flag.
> Perhaps these interfaces being discussed could take a parameter
> for address space rather than a flag. I always thought that
> the struct uio uio_segflg should be such a parameter rather
> than a flag or enumeration.

that would pose a more serious patch than the one i am preparing though not 
a bad idea at all, thanks.

Regards,
Reinoud

--dWYAkE0V1FpFQHQ3
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQEVAwUBQw44QoKcNwBDyKpoAQLPHwf+I6s7FJIO6f2sn6r6CjNyDwKlXhpFDArH
UfhyqeFx2ulTWYpxe/lkkdImaqRKRXLRFSjAt3sJvtf3ft0ESqUTaf6inO7dvM/n
mVh9Xd+EJT2y5lYEYy4e/X0wjbHGomzHkxv94X/6GN2drE758yABnUUZ0xpowzht
/WyXZ2ACjpNzObKiqdk/2mL+MlMWj+w4bR58mM3LsmGZeCX/RObTv/gn5Ny/+BeC
Z3T0UsMC0+SfEmwV7h6wx8q4u20D6m1cwwkL9kqPhrQ1nCpaPr3OyE76BMhvh+i4
EHF4FtSycJxB+QI1UAhxApGXzNfcisquLwZun2DF2dU0RKMapvhmGw==
=kgWY
-----END PGP SIGNATURE-----

--dWYAkE0V1FpFQHQ3--