Let's suppose that a process executes an open( ) system call on a device file (either of type block or character). The operations performed by the system call have already been described in Section 12.6.1. Essentially, the corresponding service routine resolves the pathname to the device file and sets up the corresponding inode object, dentry object, and file object.
Assuming that the device file is old-style, the inode object is initialized by reading the corresponding inode on disk through a suitable function of the filesystem (usually ext2_read_inode( ); see Chapter 17). When this function determines that the disk inode is relative to a device file, it invokes init_special_inode( ), which initializes the i_rdev field of the inode object to the major and minor numbers of the device file, and sets the i_fop field of the inode object to the address of either the def_blk_fops table or the def_chr_fops table, according to the type of device file. The service routine of the open( ) system call also invokes the dentry_open( ) function, which allocates a new file object and sets its f_op field to the address stored in i_fop—that is, to the address of def_blk_fops or def_chr_fops once again. The contents of these two tables are shown in the later sections Section 18.104.22.168 and Section 13.5; thanks to them, any system call issued on a device file will activate a device driver's function rather than a function of the underlying filesystem. [5!
[51 If the device file is a virtual file in the devfs filesystem, the mechanism is slightly different: the devfs filesystem layer does not invoke init_special_inode( ); rather, any devfs device file has a custom open method (the devfs_open( ) function), which is invoked by dentry_open( ) . It is the job of devfs_open( ) function to rewrite the f_op field of the file object in such a way to customize the operations triggered by the system calls.
I [email protected] RuBoard
Was this article helpful?