tailieunhanh - linux device drivers 2nd edition phần 4

Cuốn sách này bao gồm các hạt nhân , với tất cả các tính năng mới mà nó cung cấp, trong khi vẫn cho một cái nhìn ngược trở lại phiên bản trước cho những người cần hỗ trợ họ. Chúng tôi hy vọng bạn sẽ thích đọc cuốn sách này như nhiều | Access Control on a Device File Single-Open Devices The brute-force way to provide access control is to permit a device to be opened by only one process at a time single openness . This technique is best avoided because it inhibits user ingenuity. A user might well want to run different processes on the same device one reading status information while the other is writing data. In some cases users can get a lot done by running a few simple programs through a shell script as long as they can access the device concurrently. In other words implementing a single-open behavior amounts to creating policy which may get in the way of what your users want to do. Allowing only a single process to open a device has undesirable properties but it is also the easiest access control to implement for a device driver so it s shown here. The source code is extracted from a device called scullsingle. The open call refuses access based on a global integer flag int scull_s_open struct inode inode struct file filp Scull_Dev dev scull_s_device device information int num NUM inode- i_rdev if filp- private_data num 0 return -ENODEV not devfs allow 1 device only spin_lock scull_s_lock if scull_s_count spin_unlock scull_s_lock return -EBUSY already open scull_s_count spin_unlock scull_s_lock then everything else is copied from the bare scull device if filp- f_flags O_ACCMODE O_WRONLY scull_trim dev if filp- private_data filp- private_data dev MOD_INC_USE_COUNT return 0 success The close call on the other hand marks the device as no longer busy. int scull_s_release struct inode inode struct file filp scull_s_count-- release the device MOD_DEC_USE_COUNT return 0 Normally we recommend that you put the open flag scull_s_count with the accompanying spinlock scull_s_lock whose role is explained in the next 165 Chapter 5 Enhanced Char Driver Operations subsection within the device structure Scull_Dev here because conceptually it belongs to the device. The scull driver however uses standalone .