Linux Device Drivers-Chapter 5 : Enhanced Char Driver Operations

Tham khảo tài liệu linux device drivers-chapter 5 : enhanced char driver operations, công nghệ thông tin, hệ điều hành phục vụ nhu cầu học tập, nghiên cứu và làm việc hiệu quả
Nội dung trích xuất từ tài liệu:
Linux Device Drivers-Chapter 5 : Enhanced Char Driver Operations Chapter 5 : Enhanced Char Driver OperationsIn Chapter 3, Char Drivers, we built a complete device driver that the usercan write to and read from. But a real device usually offers morefunctionality than synchronous read and write. Now that were equippedwith debugging tools should something go awry, we can safely go ahead andimplement new operations.What is normally needed, in addition to reading and writing the device, isthe ability to perform various types of hardware control via the devicedriver. Control operations are usually supported via the ioctl method. Thealternative is to look at the data flow being written to the device and usespecial sequences as control commands. This latter technique should beavoided because it requires reserving some characters for controllingpurposes; thus, the data flow cant contain those characters. Moreover, thistechnique turns out to be more complex to handle than ioctl. Nonetheless,sometimes its a useful approach to device control and is used by ttys andother devices. Well describe it later in this chapter in Device ControlWithout ioctl.As we suggested in the previous chapter, the ioctl system call offers a devicespecific entry point for the driver to handle commands. ioctl is devicespecific in that, unlike read and other methods, it allows applications toaccess features unique to the hardware being driven, such as configuring thedevice and entering or exiting operating modes. These control operations areusually not available through the read/write file abstraction. For example,everything you write to a serial port is used as communication data, and youcannot change the baud rate by writing to the device. That is what ioctl isfor: controlling the I/O channel.Another important feature of real devices (unlike scull) is that data beingread or written is exchanged with other hardware, and some synchronizationis needed. The concepts of blocking I/O and asynchronous notification fillthe gap and are introduced in this chapter by means of a modified sculldevice. The driver uses interaction between different processes to createasynchronous events. As with the original scull, you dont need specialhardware to test the drivers workings. We will definitely deal with realhardware, but not until Chapter 8, Hardware Management.ioctlThe ioctl function call in user space corresponds to the following prototype: int ioctl(int fd, int cmd, ...);The prototype stands out in the list of Unix system calls because of the dots,which usually represent not a variable number of arguments. In a realsystem, however, a system call cant actually have a variable number ofarguments. System calls must have a well-defined number of argumentsbecause user programs can access them only through hardware gates, asoutlined in User Space and Kernel Space in Chapter 2, Building andRunning Modules. Therefore, the dots in the prototype represent not avariable number of arguments but a single optional argument, traditionallyidentified as char *argp. The dots are simply there to prevent typechecking during compilation. The actual nature of the third argumentdepends on the specific control command being issued (the secondargument). Some commands take no arguments, some take an integer value,and some take a pointer to other data. Using a pointer is the way to passarbitrary data to the ioctl call; the device will then be able to exchange anyamount of data with user space.The ioctl driver method, on the other hand, receives its arguments accordingto this declaration: int (*ioctl) (struct inode *inode, struct file*filp, unsigned int cmd, unsigned long arg);The inode and filp pointers are the values corresponding to the filedescriptor fd passed on by the application and are the same parameterspassed to the open method. The cmd argument is passed from the userunchanged, and the optional arg argument is passed in the form of anunsigned long, regardless of whether it was given by the user as aninteger or a pointer. If the invoking program doesnt pass a third argument,the arg value received by the driver operation has no meaningful value.Because type checking is disabled on the extra argument, the compiler cantwarn you if an invalid argument is passed to ioctl, and the programmer wontnotice the error until runtime. This lack of checking can be seen as a minorproblem with the ioctl definition, but it is a necessary price for the generalfunctionality that ioctlprovides.As you might imagine, most ioctl implementations consist of a switchstatement that selects the correct behavior according to the cmd argument.Different commands have different numeric values, which are usually givensymbolic names to simplify coding. The symbolic name is assigned by apreprocessor definition. Custom drivers usually declare such symbols i ...