Subject: Re: COMPAT_NETBSD32's execve, copy/paste of code
To: Quentin Garnier <cube@cubidou.net>
From: Christos Zoulas <christos@zoulas.com>
List: tech-kern
Date: 07/11/2005 08:51:04
On Jul 11,  7:20am, cube@cubidou.net (Quentin Garnier) wrote:
-- Subject: Re: COMPAT_NETBSD32's execve, copy/paste of code

| Ok, I've changed that.
| 
| Now, what about the smart copyin/copyout?  Are they feasible?  If not,
| will it be ok if I change quite a few syscalls to be passed a
| copyout/copyin function as a parameter?  There's wait4, and I know I
| could fix getitimer/setitimer in a similar way (setitimer is currently
| broken in COMPAT_NETBSD32).

Yes, that would be fine. I don't think that it is possible to write
a smart copyin/copyout that will work on all architectures because it
is possible that you will not be able to tell if you are referring to
a userland or a kernel address by just the value of the address that
gets passed in.

| Actually, I think that almost all the rip-offs in compat/netbsd32 can
| be fixed that way.  That means that for each of them I'll have to do
| the following:
|   o create a helper function for the syscall that does the work, while
|     the sys_<syscall> function hardly does anything but getting the
|     arguments for the syscall
|   o make the helper function take a copyout/copyin function as a
|     parameter so that the netbsd32 code can call it with a specialised
|     function
| 
| Also, should the helper functions be kept in the namespace of the
| syscall (like I'm declaring doexecve() in exec.h), or wouldn't it be
| wiser to have them declared in some sort of compat_netbsd32.h which
| makes their purpose explicit and avoid having all the dostuff()
| functions everywhere in the system headers?

The historical naming convention so far has been syscall1() or something.
Look at sigaction. Although the dosyscall() names are fine too. We should
pick and and go with it.

christos