Looking at kernel objectsOur ‘/proc/netdevs’ pseudo-fileThe LKM’s source-codeUser-space/Kernel-spaceLinux device driversHardware’s operationsA few devices are ‘simple’‘dram.c’Using our ‘fileview’ utilitySlide 10Kernel’s ‘helper-functions’Memory-mappingWhat does ‘kmap()’ do?The ‘mem_map[ ]’ arrayThe function-prototypesOur driver ‘read()’ method…‘read()’ method (continued)Another argument-value pitfall…The driver’s solution…The ‘llseek()’ method‘llseek()’ implementationDemo: ‘vwnetdev.cpp’Our ‘offsets.c’ moduleIn-class exercise #1In-class exercise #2Looking at kernel objectsHow a character-mode Linux device driver can be useful in viewing a ‘net_device’ structureOur ‘/proc/netdevs’ pseudo-file•We wrote a Loadable Kernel Module that creates a pseudo-file allowing users to see some information about the kernel’s data lo struct net_device eth0 struct net_device eth1 struct net_deviceThe LKM’s source-code#include <linux/module.h>#include <linux/proc_fs.h>char modname[ ] = “netdevs”;…MODULE_LICENSE(“GPL”); netdevs.cmodule_init()module_exit() my_get_info()some header-filessome global datathis module’s ‘payload’ function required module administration functionsUser-space/Kernel-space‘cat’ application program open read write (etc) standard runtime library operating system kernel netdevs.ko installable module LINUX privilege barrier user-space (restricted privileges) kernel-space (unrestricted privileges)Linux device drivers•There is another kind of LKM, written to control the system’s hardware devices rather than merely to expose information•Its code-structure will depend on the type of hardware device it is intended to control–‘character’ devices–‘block’ devices–‘network interface’ devicesHardware’s operations•In order to write the software that controls a particular device, the programmer needs to know details about its capabilities and about its mechanisms for being controlled•This information is found in programming manuals, produced by the manufacturer•These manuals may or not be available to the general public (often are ‘proprietary’)A few devices are ‘simple’•If a particular device’s operations are very simple to understand, we may not need to consult the manufacturer’s documentation (just use ‘common sense’ and guesswork)•EXAMPLE: The computer system’s main memory offers us an easy-to-understand hardware component for which we can directly write a device-driver module‘dram.c’•Two benefits of having a device-driver for the computer’s physical memory are: –We can directly look at kernel data-structures using ‘unprivileged’ application-programs–We get to see the general code-structure for Linux device-drivers in the simplest of casesUsing our ‘fileview’ utility •Our previous ‘netdevs.c’ module tells us where the ‘struct net_device’ objects are located in our system’s physical memory•So we can use ‘fileview’ to inspect these kernel data-structures once we’ve loaded our ‘dram.ko’ device-driver into the kernel Timeout for an in-class demonstrationThe code-structure for ‘dram.c’#include <linux/module.h>#include <linux/highmem.h>…char modname[ ] = “dram”;int my_major = 85;…MODULE_LICENSE(“GPL”); dram.cmodule_init()module_exit() my_read()some header-filessome global data this module’s ‘payload’ (its ‘method’ functions and its ‘file_operations’ structure) required module administration functions my_llseek() my_fopsKernel’s ‘helper-functions’•The Linux kernel provides quite a few aids to the authors of device-driver code:– ‘register_chrdev()’ and ‘unregister_chrdev()’– ‘copy_to_user()’ and ‘copy_from_user()’– ‘kmap()’ and ‘kunmap()’•The kernel also exports some of its ‘global variables’ (which drivers can reference):– ‘num_physpages’ and ‘mem_map[ ]’Memory-mapping user space kernel space CPU’s virtual address-spaceHMA896-MB physical RAMThere is more physical RAM in our classroom’s systems than can be ‘mapped’ into the available address-range for kernel virtual addresses = persistent mapping = transient mappingsWhat does ‘kmap()’ do?•The ‘kmap()’ helper-function allows your driver to create a temporary mapping for any one 4-KB ‘page’ of physical memory to some unused virtual address in kernel-space, then later ‘kunmap()’ lets your driver discard that mapping when it’s no longer needed (so there will be available that kernel-address for later reuse)The ‘mem_map[ ]’ array•The kernel creates an array of structures, named ‘mem_map[ ]’, whose entries hold detailed information about how each 4KB page of physical RAM is now being used•The global variable named ‘phys_mem’ stores the total number of array-entries, and hence can be used by your driver to determine the amount of installed RAMThe function-prototypes void *kmap( struct page *page_ptr ); This function accepts a pointer to an entry of type ‘struct page’ in the kernel’s ‘mem_map[ ]’ array, and returns a kernel address where that page of physical RAM has been temporarily ‘mapped’ void kunmap( void *virt_addr ); This function accepts an address where the kernel temporarily has mapped a page of physical RAM and it deletes that mapping, thus freeing the address for reuse later when the kernel is asked to setup a different temporary mapping of physical RAM into kernel-spaceOur driver ‘read()’ method…•It has to support the traditional stream-of-bytes paradigm, so a ‘sanity check’ will be needed for the caller’s argument-values ssize_t my_read( struct file *file, char *buf, size_t count, loff_t *pos ); // There’s nothing to be ‘read’ beyond the end of physical RAM if ( *pos >= dram_size ) return 0;number of bytes that caller wants to read the current position of the file-pointer Physical RAM*pos dram_size‘read()’ method (continued)•Our driver has to accommodate the CPU’s ‘page-granular’ memory-architecture, and the ‘kmap()’ function’s ability to map one-page-at-a-time*pos int page_number = *pos / PAGE_SIZE; int page_indent = *pos % PAGE_SIZE; if ( page_indent + count > PAGE_SIZE ) count = PAGE_SIZE – page_indent; struct page *pp = &mem_map[ page_number ]; void *from = kmap( pp ) + page_indent; int more =
View Full Document
Unlocking...