* Nick Gimbrone <Nicholas.Gimbrone@Comcast.Net> [020312 23:07] wrote:
> Thanks, that's what I figured was likely occuring (the last operating system I
> was working on would add buffer space for this type case, but this smelled like
> a full buffer issue ;-). In this particular case I can easilly pass the raw data
> up to userland for formatting, and figured that is what I'd have to do (unless
> someone had a simpler "turn this knob" solution for the short term ;-).
> 
> This leads me to the next question, my first thought was to use copyout() to
> pass the raw data up from the ioctl() routine for a pseudo-device to userland
> for formatting... but attempts to make that work failed (likely due to my not
> completely understanding the interface for passing the buffer address between
> layers). 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. ;-)

Afaik you can use a simple IO ioctl (not IOWR/IORD/IOWR), the 'data'
_should_ be the pointer passed via ioctl.

If you want to play around and see what's going on basically
what you should do here is take the "data" pointer given to you and
do this in the kernel:

printf("%p, %p\n", data, *(char *)data);

then in your userland app print the pointer, you should be able
to figure out exactly what's going on from there.

the IO ioctl just gives you the data pointer, the IORD/IOWR/IORW
ones will give you a pointer 'data' that points to a structure
that:
  was copied in from userspace    from the pointer given to ioctl
  will be copied out to userspace             ""
  was copied in and will be copied back out   ""
respectively.

at least that's my recollection.

-Alfred