Prerequisites

• Comfortable reading/writing files with basic shell commands (echo, cat, ls)
• A Linux board or SBC with accessible GPIO pins is helpful but not required to follow along
• Completion of the earlier lectures on device discovery and sysfs is recommended

Do You Need a Kernel Driver at All?

It’s tempting to reach for kernel module code the moment you need to talk to a new piece of hardware, but that’s often more work than the task requires. A meaningful slice of embedded hardware — buttons, LEDs, relays, many sensors, EEPROMs on I2C — can be driven entirely from an ordinary user-space program, without writing a single line inside the kernel. Before starting a driver, it’s worth pausing and asking whether a generic, already-existing kernel interface can do the job for you.

User-space code has real advantages: it’s far easier to write and debug with familiar tools (gdb, printf, strace), a bug in it can’t crash the whole system the way a kernel bug can, and it isn’t bound by the kernel’s GPL licensing the way an in-tree module is. That last point matters for some commercial products, though it isn’t by itself a strong technical reason to avoid kernel space — it’s a business consideration, not an engineering one.

Two Categories of User-Space Hardware Access

Generic user-space-accessible devices split cleanly into two groups, and it’s worth knowing which one you’re dealing with because the programming model is different for each.

The rest of this lecture focuses on the first category, using GPIO as the running example, because it’s the interface almost every embedded engineer touches first.

GPIO: The Simplest Digital Interface

General Purpose Input/Output, or GPIO, is about as close to bare metal as user space gets. Each GPIO line maps directly to a physical pin, and each one can be configured as an input or an output. Because it’s just a pin you can toggle in software, GPIO can even be used to implement higher-level protocols like I2C or SPI purely in software — a technique usually called bit-banging. The catch is timing: software-driven toggling is limited by scheduler latency and CPU cycles, so it’s rarely fast or precise enough for anything beyond low-speed or tolerant protocols. The everyday use cases are simpler and more common — reading push buttons and digital sensors, driving LEDs, motors, and relays.

Most SoCs group their GPIO lines into registers, commonly 32 lines per register, and route them out to package pins through a multiplexer (a “pin mux”) that decides whether a given physical pin behaves as GPIO or as some other peripheral function. There can also be extra GPIO lines off-chip — for example on a power-management IC or a dedicated GPIO expander reached over I2C or SPI. All of that hardware diversity is handled by one kernel-wide framework, gpiolib. Despite the name it isn’t a library you link against; it’s the internal infrastructure that every GPIO chip driver plugs into so user space sees one consistent interface regardless of which vendor made the silicon. The per-chip drivers themselves live under drivers/gpio/ in the kernel source, and the framework’s design is documented under Documentation/driver-api/gpio/.

A First Look: Listing GPIO Chips

On any current kernel, the modern entry point for discovering GPIO hardware is the libgpiod userspace tools, which talk to the /dev/gpiochipN character devices. This has replaced the old sysfs-based /sys/class/gpio interface, which is deprecated and, on many current kernel configurations, disabled outright — a detail worth knowing before you go looking for tutorials online, since a lot of older material still teaches the removed interface. We’ll cover the full modern workflow in the next lecture; for now, here’s what discovery looks like on a typical board:

$ gpiodetect
gpiochip0 [gpio-controller-a] (32 lines)
gpiochip1 [gpio-controller-b] (32 lines)

$ gpioinfo gpiochip0
gpiochip0 - 32 lines:
        line   0:      unnamed       unused   input  active-high
        line   1:    "user-led"      unused  output  active-high
        line   2:   "user-button"    unused   input  active-high

Each chip corresponds to one GPIO register or controller; gpioinfo shows you every line on it, its current direction, and whether the kernel already claims it for something else. That’s the modern equivalent of what the old sysfs base and ngpio files used to tell you, just exposed through a proper character-device API instead of loosely-typed sysfs files.

Kernel-Space vs User-Space: Making the Call

A reasonable rule of thumb: if the device is simple, low-speed, and only one application needs to touch it, user space is usually the right call. If other kernel subsystems need to know the device exists — for example, a button that should generate standard input events, or an LED that should respond to system triggers like heartbeat or disk activity — writing a proper kernel driver that plugs into the matching framework is worth the extra effort.

Common Mistakes

• Following an old sysfs-GPIO tutorial and being confused when /sys/class/gpio/export doesn’t exist on a current kernel
• Trying to bit-bang a timing-sensitive protocol purely from user space and being surprised by jitter
• Writing a kernel driver for something that a generic user-space interface already covers
• Forgetting that a GPIO line already claimed by another driver can’t be requested again from user space

Best Practices

• Check gpioinfo before assuming a line is free — a pin mux or another driver may already own it
• Reach for a kernel driver only when you need interrupt-context timing or integration with another subsystem
• Prefer the character-device GPIO API over sysfs for anything you write today; sysfs GPIO is deprecated
• Keep bit-banged protocols to low-speed, tolerant use cases only

Summary

User-space device access is a legitimate, often better, alternative to writing a kernel driver for simple hardware. GPIO is the clearest example: gpiolib gives every chip a consistent internal representation, and modern kernels expose that through /dev/gpiochipN character devices rather than the old, now-deprecated sysfs files. Knowing which category — attribute-file or bus-node — your hardware falls into, and weighing kernel-space against user-space tradeoffs honestly, will save you from writing driver code you didn’t need. The next lecture in this free linux device drivers course goes hands-on: exporting, reading, writing, and catching interrupts on real GPIO lines with the current API.

FAQ