udev is targeted at Linux kernels 2.6 and beyond to provide a userspace solution for a dynamic /dev directory, with persistent device naming. The previous /dev implementation, devfs, is now deprecated, and udev is seen as the successor. udev vs devfs is a sensitive area of conversation - you should read this document before making comparisons.

Over the years, the things that you might use udev rules for has changed, as well as the flexibility of rules themselves. On a modern system, udev provides persistent naming for some device types out-of-the-box, eliminating the need for custom rules for those devices. However, some users will still require the extra level of customisation.

This document assumes that you have udev installed and running OK with default configurations. This is usually handled by your Linux distribution.

This document does not cover every single detail of rule writing, but does aim to introduce all of the main concepts. The finer details can be found in the udev man page.

This document uses various examples (many of which are entirely fictional) to illustrate ideas and concepts. Not all syntax is explicitly described in the accompanying text, be sure to look at the example rules to get a complete understanding.

udev (user space /dev) is a user space system that enables the operating system administrator to register user space handlers for events. The events received by udev's daemon are mainly generated by the Linux kernel in response to physical events relating to peripheral devices. As such, udev's main purpose is to act upon peripheral detection and hot-plugging, including actions that return control to the kernel, e.g. loading kernel modules or device firmware. Another component of this detection is adjusting the permissions of the device to be accessible to non-root users and groups.

As the successor of devfsd and hotplug, udev also manages device nodes in the /dev directory by adding, symlinking and renaming them. udev replaces the functionality of both hotplug and hwdetect.

udev handles separate events concurrently (in parallel), leading to a potential performance improvement over older systems.

This role installs and manages gitea or forgejo. A painless self-hosted Git service. Gitea is a community managed lightweight code hosting solution written in Go. Forgejo is a fork of it. Source code & screenshots gitea. Source code forgejo. This role is also Part of the Ansible-Collection l3d.git.

As many of you know, I have moved almost all my repositories from Github to Codeberg a while ago. Now I want to take it to the next level: Build my own little CI/CD engine!

Now, codeberg offers CI/CD with their Woodpecker instance at ci.codeberg.org, which I used in the past for example to build this blog but as codeberg is based on forgejo, you can have an even more interesting way to build your stuff — Forgejo Actions. So let’s explore that road!