Subject: Re: COPYIN/COPYOUT macro problems Re: IOCTL implementation and kernel/userland addresses
To: Reinoud Zandijk <reinoud@netbsd.org>
From: Jason Thorpe <thorpej@shagadelic.org>
List: tech-kern
Date: 08/25/2005 12:44:52
On Aug 25, 2005, at 12:09 PM, Reinoud Zandijk wrote:

> you are 100% right.... i didn't think of return values so functions  
> might
> be handier yes oh and i choose memcpy since kcopy AFAIK is aliased to
> memcpy anyway but it might be changed one day yeah.

No, kcopy() is NOT aliased to memcpy().  It performs similar error  
checking to copyin()/copyout().

> We could opt for a more generic kcopyin() function :
>
> int kucopyin(int kernelspace, void *uaddr, void *kaddr, int len) {

void *from, void *to, size_t len

> int retval;
>
> if (!kernelspace) {
> return copyin(uaddr, kaddr, len);
> };
>
> /*
> * returning anything other than 0 is meaningless for it would have
> * panicked the kernel allready if the address was not valid.
> */
> kcopy(uaddr, kaddr, len);
> return 0;

No, return the error here.  kcopy() is defined to return an error  
code, and will.  UBC relies on this.

> }
>
> where the flag `kernelspace' being non-zero means use in-kernel  
> transfers.
> This way checking for the FKIOCTL flag and/or using uio's uio_seg {
> UIO_USERSPACE, UIO_SYSSPACE } would be consistent.

I would prefer to see the UIO_*SPACE enums to be used, rather than  
just a boolean.

>
> I choose `kucopyin' for its either kernel or user addresses.  
> kcopyin could
> also be used though copyin is allways kernel stuff anyway so  
> kcopyin could
> confuse...
>
> would this be better?
>
> Reinoud
>

-- thorpej