How to Find Sample Source Files for Linux Device Drivers, Third Edition

Where can I find sample source files for Linux Device Drivers, Third Edition?

That was published by O'Reilly's publisher, it might be worth your while to check there at their site. The link is here. Also is the link to their source code.

Edit: Adding another link.

Hope this helps

Study device driver source files?

Linux Source directory and description :

arch/ -
The arch sub-directory contains all of the architecture specific kernel code.

Example :
1. 'arch/arm/' will have your board related configuration file.
    like 'arch/arm/mach-omap/' will have omap specific source code.
2. 'arch/arm/config' Generates a new kernel configuration with the
    default answer being used for all options. The default values
    are taken from a file located in the arch/$ARCH/defconfig
    file,where $ARCH refers to the specific architecture for which
    the kernel is being built.
3. arch/arm/boot have kernel zImage, dtb image after compilation.

block/ -
This folder holds code for block-device drivers. Block devices are devices that accept and send data in blocks. Data blocks are chunks of data instead of a continual stream.

crypto/ -
This folder contains the source code for many encryption algorithms.

 example, “sha1_generic.c” is the file that contains the code for
           the sha1 encryption algorithm.

Documentation/ -
It has kernel related information in text format.

drivers/ - All of the system's device drivers live in this directory. They are further sub-divided into classes of device driver.

 Example,
 1. drivers/video/backlight/ has blacklight driver source which
    will control display brightness.
 2. drivers/video/display/ has display driver source. 
 3. drivers/input/ has input driver source code. like touch,
    keyboard and mouse driver.
 4. drivers/char/ has charter driver source code.
 5. drivers/i2c/ has i2c subsystem and driver source code.
 6. drivers/pci/ has pci subsytem and driver related source code.
 7. drivers/bluetooth  has Bluetooth driver file.
 8. drivers/power has power and battery driver.

firmware/ -
The firmware folder contains code that allows the computer to read and understand signals from devices. For illustration, a webcam manages its own hardware, but the computer must understand the signals that the webcam is sending the computer.
fs/ -
All of the file system code. This is further sub-divided into directories, one per supported file system, for example vfat and ext2.
kernel/ -
The code in this folder controls the kernel itself. For instance, if a debugger needed to trace an issue, the kernel would use code that originated from source files in this folder to inform the debugger of all of the actions that the kernel performs. There is also code here for keeping track of time. In the kernel folder is a directory titled "power". Some code in this folder provide the abilities for the computer to restart, power-off, and suspend.
net/ -
net
The kernel's networking code.
lib
This directory contains the kernel's library code. The architecture specific library code can be found in arch/*/lib/.
scripts
This directory contains the scripts (for example awk and tk scripts) that are used when the kernel is configured.
lib/ -
This directory contains the kernel's library code. The architecture specific library code can be found in arch/*/lib/.
scripts/ -
This directory contains the scripts (for example awk and tk scripts) that are used when the kernel is configured.
mm/ -
This directory contains all of the memory management code. The architecture specific memory management code lives down in arch/*/mm/, for example arch/i386/mm/fault.c.
ipc/ -
This directory contains the kernels inter-process communications code.
**init/ -**The init folder has code that deals with the startup of the kernel (INITiation). The main.c file is the core of the kernel. This is the main source code file the connects all of the other files.
sound/ - This is where all of the sound card drivers are.

There are few more directory certs, crypto, security, include, virt and usr etc....

scull' device from ldd3 is not shown under /dev/

SOLUTION:

Of course, I was doing the things in the wrong way: in order to load CORRECTLY the scull device module, in the book's source code and, also, in the other link of the question, there is load_scull script that does everything for you.

# source scull_load 
# lsmod 
Module                  Size  Used by
scull                  20480  0
# ls -l /dev/ | grep scull
lrwxrwxrwx 1 root root           6 Dec 19 15:00 scull -> scull0
crw-rw-r-- 1 root staff   243,   0 Dec 19 15:00 scull0
crw-rw-r-- 1 root staff   243,   1 Dec 19 15:00 scull1
crw-rw-r-- 1 root staff   243,   2 Dec 19 15:00 scull2
crw-rw-r-- 1 root staff   243,   3 Dec 19 15:00 scull3
lrwxrwxrwx 1 root root          10 Dec 19 15:00 scullpipe -> scullpipe0
crw-rw-r-- 1 root staff   243,   4 Dec 19 15:00 scullpipe0
crw-rw-r-- 1 root staff   243,   5 Dec 19 15:00 scullpipe1
crw-rw-r-- 1 root staff   243,   6 Dec 19 15:00 scullpipe2
crw-rw-r-- 1 root staff   243,   7 Dec 19 15:00 scullpipe3
crw-rw-r-- 1 root staff   243,  11 Dec 19 15:00 scullpriv
crw-rw-r-- 1 root staff   243,   8 Dec 19 15:00 scullsingle
crw-rw-r-- 1 root staff   243,   9 Dec 19 15:00 sculluid
crw-rw-r-- 1 root staff   243,  10 Dec 19 15:00 scullwuid

IOCTL Linux device driver

An ioctl, which means "input-output control" is a kind of device-specific system call. There are only a few system calls in Linux (300-400), which are not enough to express all the unique functions devices may have. So a driver can define an ioctl which allows a userspace application to send it orders. However, ioctls are not very flexible and tend to get a bit cluttered (dozens of "magic numbers" which just work... or not), and can also be insecure, as you pass a buffer into the kernel - bad handling can break things easily.

An alternative is the sysfs interface, where you set up a file under /sys/ and read/write that to get information from and to the driver. An example of how to set this up:

static ssize_t mydrvr_version_show(struct device *dev,
        struct device_attribute *attr, char *buf)
{
    return sprintf(buf, "%s\n", DRIVER_RELEASE);
}

static DEVICE_ATTR(version, S_IRUGO, mydrvr_version_show, NULL);

And during driver setup:

device_create_file(dev, &dev_attr_version);

You would then have a file for your device in /sys/, for example, /sys/block/myblk/version for a block driver.

Another method for heavier use is netlink, which is an IPC (inter-process communication) method to talk to your driver over a BSD socket interface. This is used, for example, by the WiFi drivers. You then communicate with it from userspace using the libnl or libnl3 libraries.

How to create a simple sysfs class attribute in Linux kernel v3.2

Even though my knowledge is still fairly low on the topic, I'm going to post an answer just because of the age of this question. If somebody else has a better answer, please post! :)

First off, I'm going to assume that you've read that whole chapter (specifically about kobjects & ksets). So just about every struct in the device driver model has these cutely included in them. If you want to manipulate the kobject for the class its self (not sure if that's wise or not), that's your struct class's dev_kobj member.

However, you want to manipulate the attributes of that class. I believe you do this by defining a (usually static), NULL-terminated array of them as follows and then assigning its address to the struct class's class_attrs member (taken from drivers/uwb/driver.c):

static struct class_attribute uwb_class_attrs[] = {
    __ATTR(beacon_timeout_ms, S_IWUSR | S_IRUGO,
           beacon_timeout_ms_show, beacon_timeout_ms_store),
    __ATTR_NULL,
};

/** Device model classes */
struct class uwb_rc_class = {
    .name        = "uwb_rc",
    .class_attrs = uwb_class_attrs,
};

When I don't know how to use something, I usually git grep the repository for somebody else who has used it and try to learn from it that way. It would seem that this is why they tend to say kernel "hackers" and not "developers".