lkml.org 
[lkml]   [2011]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Which one corresponds to ioctl in the file_operations struct in linux/fs.h?
Date
On Thursday 01 December 2011, Tvrtko Ursulin wrote:
> On Thursday 01 Dec 2011 07:40:49 Peng Yu wrote:
> > Hi,
> >
> > I have some driver code for older version of kernel. It refers to
> > ioctl in the file_operations struct. But this field is change in
> > kernel 3.0.0-13
> >
> > I find the following in linux/fs.h
> >
> > 1566 long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
> > 1567 long (*compat_ioctl) (struct file *, unsigned int, unsigned long);
> >
> > Does anybody know which one I should use in order to migrate the
> > driver code to the newer version of kernel? Thanks!
>
> From Documentation/filesystems/vfs.txt:
>
> unlocked_ioctl: called by the ioctl(2) system call.
>
> compat_ioctl: called by the ioctl(2) system call when 32 bit system calls
> are used on 64 bit kernels.
>
> You don't need compat_ioctl if your ioctl arguments are 32/64-bit safe.

Actually, you should always provide a .compat_ioctl pointer, but if
all commands are 32/64 bit safe, it can point to the same function,
or (slightly safer) be a wrapper like

static long my_compat_ioctl(struct file *f, unsigned int cmd, unsigned long arg)
{
return my_ioctl(f, cmd, (unsigned long)compat_ptr(arg));
}

Strictly speaking, the first option assumes that all commands
take no argument or integers directly encoded in the 'arg', while
the second option assumes that all commands take either no argument
or a pointer to an argument in memory.

Arnd


\
 
 \ /
  Last update: 2011-12-01 13:47    [W:0.042 / U:0.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site