The document discusses various debugging techniques for the Linux kernel including: 1. Enabling debugging configuration options like CONFIG_DEBUG_KERNEL and CONFIG_DEBUG_SLAB. 2. Using printk statements with different log levels for debugging. 3. Querying information from /proc and using ioctl calls. 4. Tools like strace, gdb, kdb, and Kgdb can help debug system faults, catch flaws in code, and set breakpoints. 5. Tracing tools like LTT allow tracing of kernel events and timing information.

1. Unit-5
CHAR DRIVERS AND DEBUGGING TECHNIQUES

2. • The Design of Scull:
– Scull stands for Simple Character Utility for Loading
Localities.
– It is Not hardware dependent
– Just acts on some memory allocated from the
kernel
– It uses part of the memory to simulate the device
– It shows the interfaces between the kernel and
the character driver
– It shows the actual installation and startup.

3. • The Design of Scull:
– There are several types of scull devices
– scull[0-3]
• This type has four members, scull0 , scull1 , scull2 and scull3 .
• Each encapsulates a memory area that is global and
persistent .
• Global means that all opens of these devices share the same
data.
• Persistent means that data isn't lost across closes and
reopens.
– scullpipe[0-3]
• Four devices that act like pipes between a reader and writer
process.
• Blocking and non-blocking reads and writes are illustrated
here.

4. • The Design of Scull:
– There are several types of scull devices
– Scullsingle:allows only one process at a time to
use the driver,
– scullpriv:private to each virtual console
– sculluid :Can be opened multiple times by one
user at a time
– scullwuid:Blocks open if another user is locking
the device

5. Major and Minor Numbers
• Char devices are accessed through names in
the file system
– Special files/nodes in /dev folder
>cd /dev
>ls –l
crw------- 1 root root 5, 1 Apr 12 16:50 console
brw-rw---- 1 root disk 8, 0 Apr 12 16:50 sda
brw-rw---- 1 root disk 8, 1 Apr 12 16:50 sda1
Char drivers are
identified by a
“c”
Block drivers are
identified by a
“b”
Major numbers
Minor numbers

6. Major and Minor Numbers
• Major number identifies the driver associated
with the device
– /dev/sda and /dev/sda1 are managed by
driver 8
• Minor number is used by the kernel to
determine which device is being referred to

7. The Internal Representation of Device
Numbers
• dev_t type is used to hold device numbers—
both the major and minor parts, defined in
<linux/types.h>
• Macros defined in <linux/kdev_t.h>
– 12 bits for the major number
• Use MAJOR(dev_t dev) to obtain the major number
– 20 bits for the minor number
• Use MINOR(dev_t dev) to obtain the minor
number
– Use MKDEV(int major, int minor) to turn
them into a dev_t

8. Allocating and Freeing Device Numbers
• To obtain one or more device numbers, use
int register_chrdev_region(dev_t first,
unsigned int count, char *name);
– first
• Beginning device number
• Minor device number is often 0
– count
• Requested number of contiguous device numbers
– name
• Name of the device

9. Allocating and Freeing Device Numbers
• Kernel can allocate a major number on the
fly(dynamic allocation)
int alloc_chrdev_region(dev_t *dev, unsigned
int firstminor, unsigned int count, char
*name);
– dev
• Output-only parameter that holds the first number on
success
– firstminor
• Requested first minor number
• Often 0

10. Allocating and Freeing Device Numbers
• To free your device numbers, use
int unregister_chrdev_region(dev_t first,
unsigned int count);

11. Some Important Data Structures
• file_operations
• file
• inode
• These are Defined in <linux/fs.h>

12. File Operations
struct file_operations {
struct module *owner;
/* pointer to the module that owns the structure prevents
the module from being unloaded while in use */
loff_t (*llseek) (struct file *, loff_t, int);
/* change the current position in a file
returns a 64-bit offset, or a negative value on errors
*/
ssize_t (*read) (struct file *, char __user *, size_t,
loff_t *);
/* returns the number of bytes read, or a negative value
on errors */
ssize_t (*aio_read) (struct kiocb *, const struct iovec *,
unsigned long, loff_t);
/* might return before a read completes */

13. File Operations
ssize_t (*write) (struct file *, const char __user *,
size_t, loff_t *);
/* returns the number of written bytes, or a negative
value on error */
ssize_t (*aio_write) (struct kiocb *,
const struct iovec *,
unsigned long, loff_t);
int (*readdir) (struct file *, void *, filldir_t);
/* this function pointer should be NULL for devices */
unsigned int (*poll) (struct file *,
struct poll_table_struct *);
/* query whether a read or write to file descriptors would
block */
int (*unlocked_ioctl) (struct file *, unsigned int,
unsigned long);
int (*compat_ioctl) (struct file *, unsigned int,
unsigned long);
/* provides a way to issue device-specific commands
(e.g., formatting) */

14. File Operations
int (*mmap) (struct file *, struct vm_area_struct *);
/* map a device memory to a process’s address */
int (*open) (struct inode *, struct file *);
/* first operation performed on the device file
if not defined, opening always succeeds, but driver
is not notified */
int (*flush) (struct file *, fl_owner_t id);
/* invoked when a process closes its copy of a file
descriptor for a device
not to be confused with fsync */
int (*release) (struct inode *, struct file *);
/* invoked when the file structure is being released */
int (*fsync) (struct file *, loff_t, loff_t, int datasync);
/* flush pending data for a file */
int (*aio_fsync) (struct kiocb *, int datasync);
/* asynchronous version of fsync */
int (*fasync) (int, struct file *, int);
/* notifies the device of a change in its FASYNC flag */

15. File Operations
int (*flock) (struct file *, int, struct file_lock *);
/* file locking for regular files, almost never
implemented by device drivers */
ssize_t (*splice_read) (struct file *, loff_t *, struct
pipe_inode_info *, size_t,
unsigned int);
ssize_t (*splice_write) (struct pipe_inode_info *, file *,
loff_t *, size_t, unsigned int);
/* implement gather/scatter read and write operations */
ssize_t (*sendpage) (struct file *, struct page *, int,
size_t, loff_t *, int);
/* called by kernel to send data, one page at a time
usually not used by device drivers */

16. File Operations
unsigned long (*get_unmapped_area) (struct file *,
unsigned long, unsigned long, unsigned long,
unsigned long);
/* finds a location in the process’s memory to map in a
memory segment on the underlying device
used to enforce alignment requirements
most drivers do not use this function */
int (*check_flags) (int);
/* allows a module to check flags passed to an fcntl call
*/
int (*setlease) (struct file *, long, struct file_lock *);
/* Establishes a lease on a file. Most drivers do not use
this function */
long (*fallocate) (struct file *file, int mode,
loff_t offset, loff_t len)
/* Guarantees reserved space on storage for a file. Most
drivers do not use this function */
};

17. The File Structure
• struct file
– Nothing to do with the FILE pointers
• Defined in the C Library
– Represents an open file
• A pointer to file is often called filp

18. The File Structure
• Some important fields
– fmode_t f_mode;
• Identifies the file as either readable or writable
– loff_t f_pos;
• Current reading/writing position (64-bits)
– unsigned int f_flags;
• File flags, such as O_RDONLY, O_NONBLOCK, O_SYNC

19. The File Structure
• Some important fields
– struct file_operations *f_op;
• Operations associated with the file
• Dynamically replaceable pointer
– Equivalent of method overriding in OO programming
– void *private_data;
• Can be used to store additional data structures
• Needs to be freed during the release method

20. The File Structure
• Some important fields
– struct dentry *f_dentry;
• Directory entry associated with the file
• Used to access the inode data structure
– filp->f_dentry->d_inode

21. The i-node Structure
• There can be numerous file structures
(multiple open descriptors) for a single file
• Only one inode structure per file

22. The i-node Structure
• Some important fields
– dev_t i_rdev;
• Contains device number
• For portability, use the following macros
– unsigned int iminor(struct inode *inode);
– unsigned int imajor(struct inode *inode);
– struct cdev *i_cdev;
• Contains a pointer to the data structure that refers to a
char device file

23. Char Device Registration
• Need to allocate struct cdev to represent
char devices
#include <linux/cdev.h>
/* first way */
struct cdev *my_cdev = cdev_alloc();
my_cdev->ops = &my_fops;
/* second way, for embedded cdev structure, call
this function – (see scull driver) */
void cdev_init(struct cdev *cdev, struct
file_operations *fops);

24. Char Device Registration
• Either way
– Need to initialize file_operations and set owner
to THIS_MODULE
• Inform the kernel by calling
int cdev_add(struct cdev *dev, dev_t num,
unsigned int count);
– num: first device number
– count: number of device numbers
• Remove a char device, call this function
void cdev_del(struct cdev *dev);

25. The open Method
• In most drivers, open should
– Check for device-specific errors
– Initialize the device (if opened for the first time)
– Update the f_op pointer, as needed
– Allocate and fill data structure in
filp->private_data

26. The release Method
• Deallocate filp->private_data
• Shut down the device on last close
– One release call per open
• Potentially multiple close calls per open due to
fork/dup
• scull has no hardware to shut down
int scull_release(struct inode *inode, struct file *filp) {
return 0;
}

27. scull’s Memory Usage
• Dynamically allocated
• #include <linux/slab.h>
– void *kmalloc(size_t size, int
flags);
• Allocate size bytes of memory
• For now, always use GFP_KERNEL
• Return a pointer to the allocated memory, or NULL if
the allocation fails
– void kfree(void *ptr);

28. read and write
ssize_t (*read) (struct file *filp, char __user *buff,
size_t count, loff_t *offp);
ssize_t (*write) (struct file *filp, const char __user *buff,
size_t count, loff_t *offp);
– filp: file pointer
– buff: a user-space pointer
• May not be valid in kernel mode
• Might be swapped out
• Could be malicious
– count: size of requested transfer
– offp: file position pointer

29. readv and writev
• Vector versions of read and write
– Take an array of structures
• Each contains a pointer to a buffer and a length

30. • Debugging Support in the Kernel:
• The following are the list of configuration options that
should be enabled for kernels used for development
• -->CONFIG_DEBUG_KERNEL
This option just makes other debugging options
available; it should be turned on but does not, by itself,
enable any features.
• -->CONFIG_DEBUG_SLAB
This crucial option turns on several types of checks in
the kernel memory allocation functions
• -->CONFIG_PROFILING
This option is found under "Profiling support." Profiling
is normally used for system performance tuning,

31. • Debugging with printk:
• There following are possible loglevel strings, defined in the header
<linux/kernel.h>;
• we list them in order of decreasing severity:
• KERN_EMERG
Used for emergency messages, usually those that precede a crash.
• KERN_ALERT
A situation requiring immediate action.
• KERN_CRIT
• Critical conditions, often related to serious hardware or software
failures.
• KERN_ERR
Used to report error conditions; device drivers often use KERN_ERR to
report hardware difficulties.

32. • Debugging by Watching:
• ----------------------
1.The strace command is a powerful tool that shows all the system calls
issued by a userspace program.
2.strace receives information from the kernel itself.
• Debugging by querying:
• ----------------------
1./proc--Proc file system (procfs) is virtual file system created on fly when
system boots and is dissolved at time of system shut down.
It contains the useful information about the processes that are currently
running, it is regarded as control and information centre for kernel.
The proc file system also provides communication medium between
kernel space and user space.
It is the best way to get relevant information is to query the system when
you need the information, instead of continually producing data.
2.ioctl
-------
ioctl (an abbreviation of input/output control) is a system call for device-
specific input/output operations and other operations which cannot be
expressed by regular system calls. It takes a parameter specifying a
request code; the effect of a call depends completely on the request code.
Request codes are often device-specific. For instance, a CD-ROM device
driver which can instruct a physical device to eject a disc would provide an
ioctl request code to do that.

33. Debugging System Faults
• Oops message:
• An “Oops” is what the kernel throws at us when it finds something
faulty, or an exception, in the kernel code. It’s somewhat like the
segfaults of user-space. An Oops dumps its message on the
console; it contains the processor status and the CPU registers of
when the fault occurred. The offending process that triggered this
Oops gets killed without releasing locks or cleaning up structures.
The system may not even resume its normal operations sometimes;
this is called an unstable state.
• System hangs:
• Although most bugs in kernel code end up as oops messages,
sometimes they can completely hang the system. If the system
hangs, no message is printed.

34. Debuggers and Related Tools
• Using gdb:
• GDB basically helps us to do four main things to catch flaws in the source code.
• Start the program, specifying arguments that may affect the general behavior.
• Stop the program on specified conditions.
• Examine the crash or when program was stopped.
• Change the code and to experiment with the modified code instantaneously.
• Kdb is simplistic shell-style interface which you can use on a system console with a
keyboard or serial console. You can use it to inspect memory, registers, process
lists, dmesg, and even set breakpoints to stop in a certain location. Kdb is not a
source level debugger, although you can set breakpoints and execute some basic
kernel run control. Kdb is mainly aimed at doing some analysis to aid in
development or diagnosing kernel problems

35. • Debuggers and Related Tools:
• ----------------------------
• Kgdb is intended to be used as a source level debugger for the Linux
kernel. It is used along with gdb to debug a Linux kernel. The expectation
is that gdb can be used to “break in” to the kernel to inspect memory,
variables and look through call stack information similar to the way an
application developer would use gdb to debug an application. It is possible
to place breakpoints in kernel code and perform some limited execution
stepping.
• User-Mode Linux (UML) is an interesting concept. It is structured as a
separate port of the Linux kernel with its own arch/um subdirectory. It
does not run on a new type of hardware, however; instead, it runs on a
virtual machine implemented on the Linux system call interface. Thus,
UML allows the Linux kernel to run as a separate, user-mode process on a
Linux system.
• The Linux Trace Toolkit (LTT) is a kernel patch and a set of related utilities
that allow the tracing of events in the kernel. The trace includes timing
information and can create a reasonably complete picture of what
happened over a given period of time.