Subject: Re: uprintf() limitations?
To: None <tech-kern@netbsd.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: tech-kern
Date: 03/13/2002 02:45:09
> Can someone point me to a good example of passing data between
> userland & kernel space in an ioctl() function for a pseudo-device
> driver?  (I keep getting EFAULT errors out of the copyout() call,
> clearly I don't understand the data address that my ioctl() was
> passed.  Something I'm sure a good example will solve. ;-)

One level of copyin/copyout is done for you by the kernel.  If your
ioctl is an _IOW or _IOWR one, the user data pointed to by ioctl's
third argument will be copied into a kernel buffer for you; if _IOR or
_IOWR, the kernel buffer will be copied back to userland.  In both
directions, the size of the copy is based on the low bits of the ioctl
command, which amounts to the size of the type passed as the third
argument to the _IO*() macro.  (For exmaple, if your ioctl is
_IOR(...,...,int) then sizeof(int) bytes will be copied automatically.)
But the copy is only one level deep; if the type is a struct and it
contains a pointer, then you do need copyin/copyout if you need to
refer to the data pointed to by it.

Of course, this is why you got EFAULT: the data argument you got was a
kernel virtual address, and you were treating it like a user address.
And since it was a piece of memory userland is not allowed to access
(most kernel VM is like that), you got EFAULT.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B