-1

I went through lot of documentations and question like how system call implemented, disassemble a system call and also my own slide at slide share Linux kernel tour but I want to know when we are opening any file, can be device, regular, pipe or socket, which part of the code is binding the system calls like open, read, write to its concerned drivers file_operation functions.

Also I am able to find the some flow of the functions and its definition in SYSCALL_DEFINEx then sys_calls etc, but as was unable to connect the dots till fops structure of driver and binding, so was little confused, is it done by udev, any other kernel demon, any other function or all functions are defined separately while driver is probed.

Looking to get some idea to connect this dots.

Community
  • 1
  • 1
Samrat Das
  • 1,781
  • 1
  • 21
  • 33

2 Answers2

1

The system call usually calls virtual fs layer function. So write system call will call vfs_open which will call file->f_op->open. This will be different functions depending upon type of file. If it is a regular file it will be file system dependent like ext4_file_open. The actual function name needs to be looked up in the file_operations structure for ext4 in this case. Similar mechanism is used to change from file system layer to driver layer.

jhoepken
  • 1,842
  • 3
  • 17
  • 24
Ram Gupta
  • 66
  • 4
  • ok fine, already mentioned these things in question. But what i asked is when we open any file, lets take /dev/sda and /dev/sdb, where sda is hard drive and sdb is usb drive both have different implementations for open, read, write. I wanted to know as we plugged the USB, it is probed and new file_ops are registered, so when we are opening sda harddrive's fops are being used and for sdb new usb fops are being used. so who is responsible for selecting the respective driver. I also knew it is differentiated using different minor numbers, but who is responsible for this? – Samrat Das Mar 31 '16 at 11:17
  • 1
    The lower layer in this case a driver is responsible to register with the upper layer either at the initialization time using some variant of register_* function. This binds the operation with the structure of upper layer and allows selection of the proper driver later when open or other function is called. This is the basic concept. But I hope it will help you in finding the answer you are looking for. – Ram Gupta Mar 31 '16 at 12:35
  • hm.. yes, need to research more. i was trying to hack something for my project. Thanks anyways! – Samrat Das Mar 31 '16 at 12:46
0

Do a reverse engineering, will get to know how these file operations are registered. From there you will know how proper drivers being used during a syscall. Trace register_chrdev

Liz Lemnitzer
  • 1
  • 4