NAME

     get_user, put_user, copy_from_user, copy_to_user - copy data
     between kernel space and user space


SYNOPSIS

     #include <asm/uaccess.h>

     err = get_user ( x, addr );
     err = put_user ( x, addr );

     bytes_left = copy_from_user(void*to, const void *from,
                                 unsigned long n );
     bytes_left = copy_to_user(void*to, const void *from,
                               unsigned long n );


DESCRIPTION

     These macros transfer data between  kernel  space  and  user
     space.  In the first example, the kernel variable x gets the
     value of the thing pointed to by addr (in user space).   For
     put_user, the value of the variable x is written starting at
     the address addr.  Note well that x is  a  variable,  not  a
     pointer.   addr  must be a properly typed pointer, since its
     type determines number of bytes that are copied.

     copy_from_user copies n bytes  from  address  from  in  user
     space to address to in kernel space.  copy_to_user copies in
     the opposite direction.

     None of these need the old verify_area() call,  as  they  do
     all the area verification on their own using the paging unit
     in the CPU hardware.  Less chance of missing address verifi-
     cation that way.  Also, the new address verification is much
     faster than the old scheme was.


RETURN VALUE

     get_user and put_user return 0 for success and  -EFAULT  for
     bad  access.   copy_from_user  and  copy_to_user  return the
     number of bytes they failed to copy (so again zero is a suc-
     cessful return).


EXAMPLES

          if (get_user(type, (char *)arg))
          return -EFAULT;
          switch (type) {
          ...

          b.maxwidth = 768;
          b.maxheight = 576;
          b.minwidth = 32;
          b.minheight = 32;
          if(copy_to_user(arg, &b, sizeof(b)))
              return -EFAULT;

          return 0;
          ...



AVAILABILITY

     Linux 2.1.4+


SEE ALSO

     verify_area(9)


AUTHOR

     Manual page by Jim Van Zandt <jrv@vanzandt.mv.com>