Train your team

DRV-101 · Device Drivers

Character Devices & sysfs

Your first working driver: character device registration, file operations, and exposing state through sysfs.

Foundation 3 days in person6 half-days online Max 14 in person

Who this course is for

Engineers writing their first Linux driver — firmware or userspace developers who need a working mental model of how a device file actually reaches their code.

Prerequisites

C programming, including pointers and structuresBasic Linux command line and file I/O from userspaceHaving compiled and loaded a kernel module once is helpful but not required

Course outline

Day 1 — Registering a character device

  • Major/minor numbers and what they actually identify
  • alloc_chrdev_region vs static majors
  • cdev_init, cdev_add and the registration order
  • device_create, udev and how /dev nodes appear
  • module_init/module_exit vs the probe model you will meet later

Day 2 — file_operations and the user boundary

  • The file_operations table: open, read, write, release, llseek
  • copy_to_user/copy_from_user and the page-fault path underneath
  • access_ok and why the check is not the copy
  • ioctl: command number encoding with _IO/_IOR/_IOW/_IOWR
  • Per-device state vs per-open state and the locking each needs

Day 3 — Exposing driver state

  • kobjects as the base object and their lifetime rules
  • sysfs attributes with DEVICE_ATTR: one value per file, no exceptions
  • Attribute groups and binary attributes
  • procfs: what it is for and what it is not for
  • debugfs for driver introspection without ABI promises

Hands-on labs

Labs follow the academy model — 35% principles, 20% guided investigation, 45% engineering studio. Every claim you make in a lab is backed by a trace, a counter or a measurement you captured yourself. How we teach

  1. Lab: Register a char device with alloc_chrdev_region and cdev_add; watch udev create the node and verify reads reach your handler
  2. Lab: Implement read/write across the user boundary, then pass a bad pointer deliberately and decode the resulting fault
  3. Lab: Add an ioctl interface with correctly encoded command numbers and drive it from a small C test program
  4. Lab: Expose counters and state through sysfs attributes and a debugfs dump file; script a reader for both
  5. Lab: Race two processes against your device, reproduce the corruption, and fix it with the right lock — verified with lockdep

Capstone project

Build a small but complete character driver: a kernel ring-buffer device with read/write, an ioctl control surface, a sysfs status attribute and a debugfs dump — delivered with a userspace test program and a fault-injection checklist demonstrating that every error path (bad pointers, failed allocations, double unload) unwinds cleanly.

What you leave with

  • A working character driver you wrote and can explain line by line
  • Correct copy_to_user/copy_from_user and ioctl patterns
  • sysfs/debugfs exposure habits that will pass review
  • Error-unwinding discipline: every allocation paired with a cleanup path
  • A userspace test harness template reusable for future drivers

How it runs

Every course follows the same model: 35% principles, 20% guided investigation, 45% engineering studio. You leave with working code, raw measurements and an evidence-based report — not a certificate of attendance. Read the methodology or see a full sample lesson.

Material is adapted to your kernel version, hardware and workload before a private delivery. For public cohorts, the environment is provided and configured.

Questions

Who is this course for?

Engineers writing their first Linux driver — firmware or userspace developers who need a working mental model of how a device file actually reaches their code. It sits at foundation level within the Device Drivers track.

What do I need to know already?

Specific prerequisites for this course: C programming, including pointers and structures; Basic Linux command line and file I/O from userspace; Having compiled and loaded a kernel module once is helpful but not required. We confirm levels before the cohort starts and adapt if a group is stronger or weaker than expected.

Can this run privately for my team?

Yes. Any course runs on-site at your offices anywhere, or live online for a distributed team, with labs adapted to your hardware and codebase.

What is the difference between in-person and online?

In person is 3 full days with hardware on your desk, capped at 14. Online is 6 half-day sessions across about two weeks so you can keep working, capped at 20, with remote lab access.

Do you invoice companies?

Yes. Purchase orders are accepted and invoicing is available in USD, EUR, GBP, SAR and CAD.

Upcoming dates

DatesWhereSeatsEarly birdRegular
15 Nov – 17 Nov 20263 full days RiyadhIn person · KAFD Conference Centre 6 of 14 SAR 6,080until 16 OctSAR 6,750
15 Nov – 17 Nov 20263 full days Kuwait CityIn person · Al Hamra Tower 11 of 14 KWD 500until 16 OctKWD 560
22 Nov – 24 Nov 20263 full days MuscatIn person · Knowledge Oasis Muscat 6 of 14 OMR 620until 23 OctOMR 690
29 Nov – 6 Dec 20266 half-days Gulf bandLive online · 09:00–13:00 GMT+3 16 of 20 US$1,170until 30 OctUS$1,300
30 Nov – 2 Dec 20263 full days OttawaIn person · Kanata North Tech Park 11 of 14 CAD 2,200until 31 OctCAD 2,450
30 Nov – 2 Dec 20263 full days TorontoIn person · MaRS Discovery District 6 of 14 CAD 2,200until 31 OctCAD 2,450
30 Nov – 7 Dec 20266 half-days Europe bandLive online · 09:00–13:00 CET 5 of 20 US$1,170until 31 OctUS$1,300
7 Dec – 9 Dec 20263 full days LondonIn person · Shoreditch Works 11 of 14 GBP 1,260until 7 NovGBP 1,400
7 Dec – 14 Dec 20266 half-days Americas bandLive online · 13:00–17:00 ET 10 of 20 US$1,170until 7 NovUS$1,300
14 Dec – 16 Dec 20263 full days BerlinIn person · Factory Görlitzer Park 6 of 14 EUR 1,490until 14 NovEUR 1,660

Dates shown for the next few months. If nothing fits, tell us where and when — cohorts are added on demand, and private delivery can be scheduled any week.

More in Device Drivers

DRV-1103 days The Unified Device Model Buses, devices, drivers and classes — the abstraction that makes probe and bind work across every subsystem. Practitioner Practitioner-taught SAR 7,880Next 25 Oct DRV-1204 days Platform Drivers & Device Tree Describing non-discoverable hardware and writing the drivers that consume that description. Practitioner Practitioner-taught SAR 10,500Next 11 Oct DRV-2013 days I2C & SPI Drivers Client drivers for the two buses embedded hardware is built from, including regmap and error recovery. Practitioner Practitioner-taught SAR 7,880Next 18 Oct DRV-2104 days USB Device Drivers The USB stack from descriptors to URBs, on both the host and gadget sides. Practitioner Practitioner-taught SAR 10,500Next 15 Nov DRV-2204 days PCI & PCIe Drivers Enumeration, BARs, MSI-X and DMA for PCIe devices, which is where most accelerator drivers live. Advanced Practitioner-taught SAR 12,000Next 1 Nov DRV-3013 days DMA Engines & Mappings Moving data without the CPU: the DMA API, coherency, IOMMU interaction and the bugs that only appear under load. Advanced Practitioner-taught SAR 9,000Next 8 Nov DRV-3103 days Interrupts & Threaded IRQs Interrupt handling from the hardware edge to the bottom half, and how to keep hard IRQ context short. Practitioner Practitioner-taught SAR 7,880Next 18 Oct