6.1. Using /proc For Input
So far we have two ways to generate output from kernel modules: we can register a device driver and mknod a device file, or we can create a /proc file. This allows the kernel module to tell us anything it likes. The only problem is that there is no way for us to talk back. The first way we'll send input to kernel modules will be by writing back to the /proc file.Because the proc filesystem was written mainly to allow the kernel to report its situation to processes, there are no special provisions for input. The struct proc_dir_entry doesn't include a pointer to an input function, the way it includes a pointer to an output function. Instead, to write into a /proc file, we need to use the standard filesystem mechanism.
In Linux there is a standard mechanism for file system registration. Since every file system has to have its own functions to handle inode and file operations[1], there is a special structure to hold pointers to all those functions, struct inode_operations, which includes a pointer to struct file_operations. In /proc, whenever we register a new file, we're allowed to specify which struct inode_operations will be used for access to it. This is the mechanism we use, a struct inode_operations which includes a pointer to a struct file_operations which includes pointers to ourmodule_input and module_output functions.
It's important to note that the standard roles of read and write are reversed in the kernel. Read functions are used for output, whereas write functions are used for input. The reason for that is that read and write refer to the user's point of view --- if a process reads something from the kernel, then the kernel needs to output it, and if a process writes something to the kernel, then the kernel receives it as input.
Another interesting point here is the module_permission function. This function is called whenever a process tries to do something with the/proc file, and it can decide whether to allow access or not. Right now it is only based on the operation and the uid of the current user (as available in current, a pointer to a structure which includes information on the currently running process), but it could be based on anything we like, such as what other processes are doing with the same file, the time of day, or the last input we received.
The reason for put_user and get_user is that Linux memory (under Intel architecture, it may be different under some other processors) is segmented. This means that a pointer, by itself, does not reference a unique location in memory, only a location in a memory segment, and you need to know which memory segment it is to be able to use it. There is one memory segment for the kernel, and one of each of the processes.
The only memory segment accessible to a process is its own, so when writing regular programs to run as processes, there's no need to worry about segments. When you write a kernel module, normally you want to access the kernel memory segment, which is handled automatically by the system. However, when the content of a memory buffer needs to be passed between the currently running process and the kernel, the kernel function receives a pointer to the memory buffer which is in the process segment. The put_user and get_user macros allow you to access that memory.
Example 6-1. procfs.c
/* procfs.c - create a "file" in /proc, which allows both input and output. */ #include |
No comments:
Post a Comment