005 Character Device Drivers DevelopmentIssues, queries, suggestions or discussion related to Linux Device drivers, character device drivers, Linux based character driver and related issues.
INTERFACING OF OPEN SYSTEM CALL INSIDE APPLICATION WITH DEVICE DRIVER IN KERNEL
The application in user space will give open( ) system call to the device file which is present in VFS (Virtual File System). This file will be connected to the device driver using major and minor number. Now, every file in the filesystem have a kernel associated data structure called struct inode{ } with it. The struct inode{ } have many important fields inside it like device id, pointer to struct file_operations{ }, pointer to struct cdev{ } etc. Now the struct cdev{ } is a device specific data structure which is connected to the actual hardware device. It also contain many important fields related to device initialisation like device id, pointer to struct file_operations{ } etc. Now, parameters like device id and reference to struct file_operations{ } are checked and verified against each other in both struct inode{ } and struct cdev{ }. If the reference to struct file_operations points to same data structure for both struct inode{ } and struct cdev{ } then the interfacing is correct.
Now the control will move to the struct file_operations which contain the references to various device driver routines like open, release, read and write. Here the reference to open( ) system call will be used and the control will move to the open device driver routine. Then the open device driver routine will fetch device id and verify it and if it is correct then it will create a new kernel data structure called struct file{ } which contain fields like f_flags, pointer to f_inode, pointer to f_op, pointer to f_pos, pointer to private_data etc. The struct file{ } is a stream represented data structure which is connected between the application process and the opened file in VFS in appropriate mode.
Then open( ) system call will fetch device id and store it in the private_data field inside the struct file{ }. The device will be opened until the device reference is preserved in private_data inside struct file.
Here we first preserved the device major and minor number in the private_data field of struct file. The device will be opened untill the private_data field will contain device id.
we have not allocated any new memory for *ldev as it points to the same memory that is allocated to *dev in the initialisation function using kmalloc
the *ldev and *dev will point to same memory but the *ldev can point to usr space and IO space memory along with kernel space memory but *dev can only point to kernel space memory only
In order to make *ldev to access usr and IO space memory, use a macro container_of() that contains three argument namely: pinter to cdev in struct inode, data type of user defined data structure (struct Dev), identifier for device specific data structure(cdev) in user defined data structure(Dev)
4: Create Device Node 5: Build Application 6: Test Driver with Application 7: Remove Character Driver 0: Exit Script Please Enter Your choice: 7 rmmod: ERROR: Module mycdd is in use __MAIN MENU__ 1: Build Character Driver 2: Insert Character Driver 3: Check Driver Messages 4: Create Device Node 5: Build Application 6: Test Driver with Application 7: Remove Character Driver 0: Exit Script
