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