- An important task of the kernel
is to make sure that
you can use your hardware.
So how exactly does that work?
Well, the kernel itself is small
and it contains essential drivers only
and additional drivers are provided dynamically.
And there's many ways in which that happens.
To start it, there is InitramFS
the initial RAM file system,
which is loaded while booting.
Also there is systemd-udevd
which takes care of loading drivers
automatically and on demand.
To access devices,
device files in the /dev directory are used.
The kernel doesn't know about device file names.
It uses the device fellow major and minor
to address the devices.
Let me show you.
So if I use ls - l on /dev/sda*
/dev/sda* is obviously your hard drive.
Then what I want you to be aware of
is this 8,0 , this 8, 0.
That's your major and your minor.
And that is what the kernel
really all knows about.
Now in /proc there is this file
with the name /proc/devices
and in /proc/devices
we have the block devices
and what do we see?
Block device 8 is sd.
What does that mean?
Well that means that
if the block device major "8" is addressed
then the kernel is going to contact the sd,
which is SCSI disk module
and that is how these major minors
allow the kernel to allocate
the right, the right modules.
You can also see that
in a different way
using lsblk, for instance.
I like this overview because
in lsblk you see not only the major and the minor
but on the left hand the device name
and on the right hand,
if the device is mounted,
you can even see the mount point.
And that's how major and minor are are used.
Now let's talk about hardware initialization a bit.
So to access hardware, the Linux kernel uses drivers
and these drivers are the kernel modules.
Drivers can be provided through the InitramFS
or loaded dynamically through systemd-udevd.
And device valves in /dev provide
user interface to the devices.
Device files are mostly auto-generated
and the device files correspond
to the device nodes
which are a major and a minor number
that the kernel uses to identify devices.
You can even create them yourselves
using the mknod command.
That's something that was useful in the past.
Nowadays they should never be necessary anymore.
Also involved in hardware management
is a sysfs file system.
So /sys is used to provide information
about devices and their attributes.
And /sys/devices is dedicated
to device information.
An easy interface to query device information
from /sys is udevadm.
Use, for instance,
udevadm info --query=all --name=/dev/sda
and you will find all the information stored
in the sysfs file system about a /dev/sda device.
Now before I'm going to show you
I want you to understand systemd-udevd a bit.
The Linux kernel initiates device loading
and next sends out uevents
to the udevd user space daemon.
Well, the systemd-udevd user space daemon
is what we should say
because udevd is the old name of the process.
Nowadays it's integrated in systemd
and the name of the process really is systemd-udevd.
systemd-uddevd catches the event
and decides how to handle it
based on attributes
that it has received in the event.
And it next reads its rules
and acts based on these rules.
It has default rules in /usr/lib/udev/rules.d
and custom rules can be stored
in /etc/udev/rules.d.
Now let me demonstrate how to use udev rules.
You can find the steps in this demo
on the slide, just for your convenience.
Let me show you.
So to start with, I need udevamd monitor
which is showing all the udev events
that are going to happen.
And now I'm plugging in the USB thumb drive.
So as you can see
the USB thumb drive is now initialized
and udevadm monitor is showing
exactly what is happening.
So it's a step-by-step procedure
where we can see that the kernel
has detected an event
and then has pass the event through udev
and based on that, the kernel can continue
and down the road, everything is loaded
that is, that is required.
So here for instance you can see SCSI disc
that is involved SCSI generic,
that's about block devices.
Then we can see that the sdb block device is created
and all of these are file names,
file names that are relative to the /sys file system.
Now the big question is,
"What exactly is going on
when stuff like this is happening?"
Well, that is determined by the udev rules.
So let's have a look at
/lib/udev/rules.d
where we have multiple rules.
We don't wanna see all 122.
So let me just go for 60.
And in 60 we have the persistent
storage.rules
and there we can see how such a rule is composed.
So it's, it's quite complex.
Here we see if the kernel detects
one of these loop devices,
then it's going to take action.
Now I don't want to go
through all of the lines in this example file.
I want to create our own.
Now how are we going to do that?
Well, we need to work
with the device that was just added.
So which device is that?
Well ls -l in /dev/disk
is showing the different device names.
lsblk is showing the different device names
from a different perspective.
And what we need is sdb.
In a udev rule
you are going to use device attributes
and to find these device attributes,
udevadm info --query=all --name=dev/sdb
It's showing all the information
on this USB thumb drive.
Now this is device-specific
and you can use this device-specific information
in the udev rules.
There's another way to display
more or less the same
information
and
that is
- -attribute-walk.
That is giving detailed information
about everything that was found
on this USB thumb drive.
And this information is the information
that you can use
in your
udev rules.
So that is what I wanna do now.
I want to create a custom rule.
So to make it easier
to create a custom rule,
I'm providing it as an example file
in the course get repository.
The name of the file's 50-custom.rules
And in this custom rule we define an action.
So the action is "add" on the subsystem "block"
and the driver involved is USB-storage
And if that is going to happen,
then we are going to
create a symbolic link.
This symbolic link is created
in the /dev directory.
So it creates /dev/usb/
We will see.
And this is the power of udev.
It allows you to run any arbitrary command
and in this case the arbitrary command is
/usr/bin/logger CUSTOMUDEV Added %k
which is printing the message to udev.
Now to have this work,
I need to make sure that we copy the custom rule
to the appropriate location.
And here we are going to respect the convention
that custom stuff is in the /etc directory.
/usr/lib is for the default stuff,
custom files are in the /etc directory,
in this case in /etc/udev/rules.d
So, there we go.
Just to make sure it's picked up,
systemctl restart
systemd-udevd
and now I'm going to
disconnect the USB thumb drive
and I'm going to reconnect it.
So how can we verify?
Well journalctl | grep CUSTOMUDEV.
And there we can see, yay,
CUSTOMUDEV Added sdb.
That's a command
that we have defined
in the custom rule file.
And that is how you can create
your own udev rules.