UIO(9)

📦
version 15.1 · 2 versions
, in freebsd 14.5, freebsd 15.1

🦋 UIO(9) — uio, uiomove, uiomove_frombuf, uiomove_nofault 💅

okay so this is a page from the Kernel Developer's Manual, section 9, and it's literally all about the device driver I/O routines bestie, strap in 🎀

✨ NAME ✨

uio, uiomove, uiomove_frombuf, uiomove_nofault — device driver I/O routines 🫶

🌸 SYNOPSIS 🌸

#include <sys/types.h>
#include <sys/uio.h>

struct uio {
        struct  iovec *uio_iov;         /* scatter/gather list */
        int     uio_iovcnt;             /* length of scatter/gather list */
        off_t   uio_offset;             /* offset in target object */
        ssize_t uio_resid;              /* remaining bytes to copy */
        enum    uio_seg uio_segflg;     /* address space */
        enum    uio_rw uio_rw;          /* operation */
        struct  thread *uio_td;         /* owner */
};

int
uiomove(void *buf, int howmuch, struct uio *uiop);

int
uiomove_frombuf(void *buf, int howmuch, struct uio *uiop);

int
uiomove_nofault(void *buf, int howmuch, struct uio *uiop);

💖 DESCRIPTION 💖

So uiomove(), uiomove_frombuf(), and uiomove_nofault() are the three functions that move data back and forth between buffers and I/O vectors — and the whole vibe is that those I/O vectors might cross the user/kernel space boundary 😭 like that's the entire point bestie.

Here's the tea: any time a read(2), write(2), readv(2), or writev(2) system call gets passed along to a character-device driver, the appropriate driver d_read or d_write entry gets called with a pointer to a struct uio handed over to it. The transfer request is literally encoded in this structure 👑. The driver itself should use uiomove() or uiomove_nofault() to get at the data inside it.

The fields in the uio structure are, one by one, no skipping:

  • uio_iov — the array of I/O vectors to be processed. In the case of scatter/gather I/O, this'll be more than one vector. slay 🌈
  • uio_iovcnt — the number of I/O vectors present.
  • uio_offset — the offset into the device.
  • uio_resid — the remaining number of bytes to process, updated after transfer.
  • uio_segflg — one of the following flags:
    • UIO_USERSPACE — the I/O vector points into a process's address space.
    • UIO_SYSSPACE — the I/O vector points into the kernel address space.
    • UIO_NOCOPY — do not copy, already in object.
  • uio_rw — the direction of the desired transfer. The supported flags are:
    • UIO_READ — transfer data from the buffers into the I/O vectors.
    • UIO_WRITE — transfer data from the I/O vectors into the buffers.
  • uio_td — the pointer to a struct thread for the associated thread; used if uio_segflg indicates that the transfer is to be made from/to a process's address space.

🧚 the nofault one is built different

The function uiomove_nofault() requires that the buffer and I/O vectors be accessible without incurring a page fault. The source and destination addresses must be physically mapped for read and write access, respectively, and neither the source nor destination addresses may be pageable. So basically, uiomove_nofault() can be called from contexts where acquiring virtual memory system locks or sleeping are prohibited — no cap, that's the whole reason it exists 🔥

⚠️ bestie read this twice: if a page fault happens, you're in trouble. This function is for the no-fault zones only.

🍓 the frombuf one is the convenience wrapper

The uiomove_frombuf() function is a convenience wrapper around uiomove() for drivers that serve data which is wholly contained within an existing buffer in memory. It validates the uio_offset and uio_resid values against the size of the existing buffer, handling short transfers when the request partially overlaps the buffer. And here's the iconic part: when uio_offset is greater than or equal to the buffer size, the result is success with no bytes transferred, effectively signaling EOF 💀✨

⭐ RETURN VALUES ⭐

On success uiomove(), uiomove_frombuf(), and uiomove_nofault() will return 0; on error they will return an appropriate error code. that's it that's the rule 💅

🎀 EXAMPLES 🎀

The idea is that the driver maintains a private buffer for its data, and processes the request in chunks of maximal the size of this buffer. Note that the buffer handling below is very simplified and will not work (the buffer pointer is not being advanced in case of a partial read), it is just here to demonstrate the uio handling. don't come for me, it says it right there 🙈

/* MIN() can be found there: */
#include <sys/param.h>

#define BUFSIZE 512
static char buffer[BUFSIZE];

static int data_available;      /* amount of data that can be read */

static int
fooread(struct cdev *dev, struct uio *uio, int flag)
{
        int rv, amnt;

        rv = 0;
        while (uio->uio_resid > 0) {
                if (data_available > 0) {
                        amnt = MIN(uio->uio_resid, data_available);
                        rv = uiomove(buffer, amnt, uio);
                        if (rv != 0)
                                break;
                        data_available -= amnt;
                } else
                        tsleep(...);    /* wait for a better time */
        }
        if (rv != 0) {
                /* do error cleanup here */
        }
        return (rv);
}

💀 ERRORS 💀

uiomove() and uiomove_nofault() will fail and return the following error code if:

In addition, uiomove_nofault() will fail and return the following error code if:

  • [EFAULT] — a page fault occurs.
😭 yes both of them are EFAULT, that's not a typo, that's just how it is

🌈 SEE ALSO 🌈

read(2), readv(2), write(2), writev(2), copyin(9), copyout(9), sleep(9) — go read those next, iykyk 🦋

👑 HISTORY 👑

The uio mechanism appeared in some early version of Unix. ancient. legendary. the blueprint fr fr ⭐

💜 AUTHORS 💜

This manual page was written by Jörg Wunsch. thank you Jörg, you ate 🫶

and that's the whole page bestie!! this one came from Debian, dated October 22, 2025, filed under UIO(9) in the Kernel Developer's Manual — go forth and move those I/O vectors 💅✨

📦 where this page comes from