Re: Which one corresponds to ioctl in the file_operations struct in linux/fs.h?

[Arnd Bergmann]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/