一、内核原型(linux2.6.28-7)
long (*compat_ioctl)(struct tty_struct *tty, struct file * file,
unsigned int cmd, unsigned long arg);
implement ioctl processing for 32 bit process on 64 bit system
Optional
二、What is compat_ioctl
There is one more method called as "compat_ioctl()" that a 64 bit driver
has to implement. It gets called when 64 bit kernel gets ioctl() call
from 32 bit user.
Tasks to be done by compat_ioctl() :
1. Acquire BKL, since kernel calls compat_ioctl without BKL.
2. 32 to 64 bit conversion for long and pointer objects passed by user
3. Process input data, get results.
4. 64 to 32 bit conversion in order to pass the output data back to user
5. Release BKL
三、中文档案
Linux 64Bit 下的 ioctl和compat_ioctl ioctl32 Unknown cmd fd
前段时间将我们的程序移植到Mips64的Linux 2.6环境下,做可行性试验。
由于用户态程程序规模太大,而且之前没有对64bit的情况做考虑,
所以,用户态程序任然使用32位模式编译,内核运行在64bit。
我们有一个内核模块之前是在2.4.21下的,拿到2.6后,把部分api做了些更改,直接编译并加载。
用户态程序在调用ioctl的时候,总是失败。
dmesg看一下内核信息,有如下类似信息:
ioctl32(add_vopp:9767): Unknown cmd fd(3) cmd(80048f00){00} arg(ff240ae0)
后来在内核中的ioctl中添加debug代码,发现根本没调用到内核中的ioctl函数。
经过查找,发现了以下资源
The new way of ioctl()
32 bit user/64 bit kernel
What is compat_ioctl ()
more on compat_ioctl
产生问题的分析:
我们的程序通过Linux的
ssize_t read(int fd, void *buf, size_t count);
系统调用从虚拟设备中读取内核中。
使用
int ioctl(int fd, int request, ...);
系统调用来对设备进行控制,并传递一些数据。
ioctl是我们扩展非标准系统调用的手段。
read系统调用,对应内核中struct file_operations 结构中的
ssize_t (*read) (struct file *filp, char *buf, size_t count, loff_t *f_pos)
当用户态位32bit, 内核位64bit的时候,
用户态的程序,和内核态的程序,在数据类型不一致。
比如指针,用户态的指针实际上是unsigned long 4Byte
内核态的指针是unsigned ong: 8Byte.
对于这种不一致,从用户态陷入内核态的时候,大部分标准调用的参数已经做了相应的转化。
不存在问题。比如ssize_t,内核态和用户态不一致,
对于这种已知类型,内核代码已经做了转换,因为他知道该怎么转,
所以我们的程序调用read,write,等系统调用,都能正确的返回结果。
再来看看ioctl系统调用,
用户态系统调用,int ioctl(int fd, int request, ...);
内核中对应的函数
int (*ioctl) (struct inode *inode, struct file *filp, unsigned int cmd, unsigned long arg)
request是请求号,用来区分不同得到请求。后面的可变参数随便选。
如果想传入或传出自定义结构,可以传个指针类型。
如果没数据传递,可以空着。
当然也可以传这个int或char之类的类型来向内核传递数据。
问题来了,内核不知道你传递的是那种类型,他无法给你转化。
总结一下:
1). Linux2.6对64bit kernel 在struct file_operation中增加了一个成员
long (*compat_ioctl) (struct file *filp, unsigned int cmd, unsigned long arg);
用来提供32位用户态程序的方法,
可以通过filp->f_dentry->d_inode方法获得。
3). 关于ioctl的请求号,经常是通过宏定义生成的
举例如下:
#define IoctlGetNetDeviceInfo _IOWR(Ioctl_Magic, 1, struct_NetDeviceInfo)
#define IoctlNetQueueInit _IOR(Ioctl_Magic, 4, struct_NetDeviceListen)
#define IoctlNetQueueDestroy _IO(Ioctl_Magic, 5)
注意_IOWR和IOR宏, 他们的最后一个参数是一个数据类型,展开时会包含sizeof()操作,
于是32bit用户态程序和64bit内核之间,生成的ioctl的request号很可能就会不同,
在compat函数中switch()的时候,就会switch不到。
要想办法避免:
提供64bit和32bit大小一致的结构。
在用户态下提供一个伪结构,伪结构和内核内的结构宽度一致。
用_IO宏,而不用_IOWR或_IOR宏,反正只是为了得到一个号码,实际传输数据大小,自己心理有数,内核代码处理好就行了。
4). 如果compat收到的最后参数arg是一个用户态指针, 它在用户态是32位的,在内核中为了保证安全,
可以使用compat_ptr(art)宏将其安全的转化为一个64位的指针(仍然是用户指针)