linux 设备驱动程序例程编译出错

如果在2.6.34kernel环境下，编译是不会出现异常了。

 

但是有些同学从fedora14 升级到了 fedora15 或是使用了 ubuntu 11.04

 

这个时候linux kernel已经升级到了2.6.38.8

 

这个时候编译就会出错。

 

第一部分：

 

init_MUTEX(LOCKNAME)未定义

 

这个宏在2.6.38.8已经被替换

 

只需要加

 

#define init_MUTEX(LOCKNAME)sema_init(LOCKNAME,1)

 

即可。

 

还有一个最重要的地方就是

 

struct file_operations

 

 

 

在这个结构中取消了ioctl，用unlocked_ioctl和compat_ioctl替换

 

具体的内容请参照下面资料

 

The ioctl() system call has long been outof favor among the kernel developers, who see it as a completely uncontrolledentry point into the kernel. Given the vast number of applications which expectioctl() to be present, however, it will not go away anytime soon. So it isworth the trouble to ensure that ioctl() calls are performed quickly andcorrectly - and that they do not unnecessarily impact the rest of the system.

 

ioctl() is one of the remaining parts ofthe kernel which runs under the Big Kernel Lock (BKL). In the past, the usageof the BKL has made it possible for long-running ioctl() methods to create longlatencies for unrelated processes. Recent changes, which have made BKL-coveredcode preemptible, have mitigated that problem somewhat. Even so, the desire toeventually get rid of the BKL altogether suggests that ioctl() should move outfrom under its protection.

 

Simply removing the lock_kernel() callbefore calling ioctl() methods is not an option, however. Each one of thosemethods must first be audited to see what other locking may be necessary for itto run safely outside of the BKL. That is a huge job, one which would be hardto do in a single "flag day" operation. So a migration path must beprovided. As of 2.6.11, that path will exist.

 

The patch (by Michael s. Tsirkin) adds anew member to the file_operations structure:

 

   long (*unlocked_ioctl) (struct file *filp, unsigned int cmd,

 

                            unsigned long arg);

 

If a driver or filesystem provides anunlocked_ioctl() method, it will be called in preference to the older ioctl().The differences are that the inode argument is not provided (it's available asfilp->f_dentry->d_inode) and the BKL is not taken prior to the call. Allnew code should be written with its own locking, and should useunlocked_ioctl(). Old code should be converted as time allows. For code whichmust run on multiple kernels, there is a new HAVE_UNLOCKED_IOCTL macro whichcan be tested to see if the newer method is available or not.

 

Michael's patch adds one other operation:

 

   long (*compat_ioctl) (struct file *filp, unsigned int cmd,

 

                          unsigned long arg);

 

If this method exists, it will be called(without the BKL) whenever a 32-bit process calls ioctl() on a 64-bit system.It should then do whatever is required to convert the argument to native data typesand carry out the request. If compat_ioctl() is not provided, the olderconversion mechanism will be used, as before. The HAVE_COMPAT_IOCTL macro canbe tested to see if this mechanism is available on any given kernel.

 

The compat_ioctl() method will probablyfilter down into a few subsystems. Andi Kleen has posted patches adding newcompat_ioctl() methods to the block_device_operations and scsi_host_templatestructures, for example, though those patches have not been merged as of thiswriting.

 

 

--------------------------------------------------------------------------------

 

 

(Log in to post comments)

 

more on compat_ioctl

 

Posted Oct 23, 2005 14:19 UTC (Sun) by arnd(subscriber, #8866) [Link]

 

There are a few noteworthy points aboutcompat_ioctl:

•If you are writing a new device driver that needs ioctl methods(which some might argue you should not do in the first place), make sure thedata structure are compatible between 32 and 64 bit, so unlocked_ioctl andcompat_ioctl can point to the same function. In particular, data structurescontaining must not contain fields that have different sizes (e.g. 'void *' or'long') or need padding (e.g. 'long long' after 'int') on 64 bit systems.

 •Asof 2.6.14, nobody has started converting the network layer to compat_ioctl, sothe next person that needs new compatibility code for socket ioctls should addthe infrastructure for that instead of adding on to fs/compat_ioctl.c.

 •While the fs/compat_ioctl.c infrastructurestill exists, it is valid for compat_ioctl methods to return -ENOIOCTLCMD foranything they don't know. This is particularly useful for block or tty devicesthat have a lot of ioctl numbers common to all drivers. The vfs layer firstcalls ->compat_ioctl and if that does not exist or returns -ENOIOCTLCMD, itscans the list of known conversions between 32 and 64 bit ioctls and if itfinds a valid conversion, it enters the native 64 bit->unlocked_ioctl/->ioctl path.