BUS_SPACE(9)

💖 BUS_SPACE(9) 💖 — bus space manipulation functions

okay so first things first: this is BUS_SPACE(9), straight out of the Kernel Developer's Manual, and it is a lot. Like, a whole family of functions. We're gonna get through it together bestie, no cap 🫶

---

✨ NAME ✨

bus_space, and honestly her entire extended friend group:

bus_space, bus_space_barrier, bus_space_copy_region_1,
bus_space_copy_region_2, bus_space_copy_region_4,
bus_space_copy_region_8, bus_space_copy_region_stream_1,
bus_space_copy_region_stream_2, bus_space_copy_region_stream_4,
bus_space_copy_region_stream_8, bus_space_free, bus_space_map,
bus_space_peek_1, bus_space_peek_2, bus_space_peek_4, bus_space_peek_8,
bus_space_poke_1, bus_space_poke_2, bus_space_poke_4, bus_space_poke_8,
bus_space_read_1, bus_space_read_2, bus_space_read_4, bus_space_read_8,
bus_space_read_multi_1, bus_space_read_multi_2, bus_space_read_multi_4,
bus_space_read_multi_8, bus_space_read_multi_stream_1,
bus_space_read_multi_stream_2, bus_space_read_multi_stream_4,
bus_space_read_multi_stream_8, bus_space_read_region_1,
bus_space_read_region_2, bus_space_read_region_4,
bus_space_read_region_8, bus_space_read_region_stream_1,
bus_space_read_region_stream_2, bus_space_read_region_stream_4,
bus_space_read_region_stream_8, bus_space_read_stream_1,
bus_space_read_stream_2, bus_space_read_stream_4,
bus_space_read_stream_8, bus_space_set_multi_1, bus_space_set_multi_2,
bus_space_set_multi_4, bus_space_set_multi_8,
bus_space_set_multi_stream_1, bus_space_set_multi_stream_2,
bus_space_set_multi_stream_4, bus_space_set_multi_stream_8,
bus_space_set_region_1, bus_space_set_region_2, bus_space_set_region_4,
bus_space_set_region_8, bus_space_set_region_stream_1,
bus_space_set_region_stream_2, bus_space_set_region_stream_4,
bus_space_set_region_stream_8, bus_space_subregion, bus_space_unmap,
bus_space_write_1, bus_space_write_2, bus_space_write_4,
bus_space_write_8, bus_space_write_multi_1, bus_space_write_multi_2,
bus_space_write_multi_4, bus_space_write_multi_8,
bus_space_write_multi_stream_1, bus_space_write_multi_stream_2,
bus_space_write_multi_stream_4, bus_space_write_multi_stream_8,
bus_space_write_region_1, bus_space_write_region_2,
bus_space_write_region_4, bus_space_write_region_8,
bus_space_write_region_stream_1, bus_space_write_region_stream_2,
bus_space_write_region_stream_4, bus_space_write_region_stream_8,
bus_space_write_stream_1, bus_space_write_stream_2,
bus_space_write_stream_4, bus_space_write_stream_8

…and what do they all do? bus space manipulation functions 💅 periodt.

---

🌸 SYNOPSIS 🌸

You start with the sacred include, obviously:

#include <machine/bus.h>

🎀 mapping & unmapping (the plumbing)

int
bus_space_map(bus_space_tag_t space, bus_addr_t address,
    bus_size_t size, int flags, bus_space_handle_t *handlep);

void
bus_space_unmap(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t size);

int
bus_space_subregion(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, bus_size_t size, bus_space_handle_t *nhandlep);

🎀 alloc & free (the ✨ fancy ✨ plumbing)

int
bus_space_alloc(bus_space_tag_t space, bus_addr_t reg_start,
    bus_addr_t reg_end, bus_size_t size, bus_size_t alignment,
    bus_size_t boundary, int flags, bus_addr_t *addrp,
    bus_space_handle_t *handlep);

void
bus_space_free(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t size);

🎀 peek & poke (look, don't touch / touch, don't look)

int
bus_space_peek_1(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint8_t *datap);

int
bus_space_peek_2(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint8_t *datap);

int
bus_space_peek_4(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint8_t *datap);

int
bus_space_peek_8(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint8_t *datap);

int
bus_space_poke_1(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint8_t *datap);

int
bus_space_poke_2(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint8_t *datap);

int
bus_space_poke_4(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint8_t *datap);

int
bus_space_poke_8(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint8_t *datap);

(yes, they all take uint8_t *datap, even the _8 ones. that's the vibe. don't question it 💀)

🎀 single reads (one byte-ish at a time)

uint8_t
bus_space_read_1(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset);

uint16_t
bus_space_read_2(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset);

uint32_t
bus_space_read_4(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset);

uint64_t
bus_space_read_8(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset);

🎀 single reads, but streaming 🌊

uint8_t
bus_space_read_stream_1(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset);

uint16_t
bus_space_read_stream_2(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset);

uint32_t
bus_space_read_stream_4(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset);

uint64_t
bus_space_read_stream_8(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset);

🎀 single writes

void
bus_space_write_1(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint8_t value);

void
bus_space_write_2(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint16_t value);

void
bus_space_write_4(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint32_t value);

void
bus_space_write_8(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint64_t value);

🎀 single writes, streaming edition 🌊

void
bus_space_write_stream_1(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint8_t value);

void
bus_space_write_stream_2(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint16_t value);

void
bus_space_write_stream_4(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint32_t value);

void
bus_space_write_stream_8(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint64_t value);

🎀 barrier (the vibe check 🚧)

void
bus_space_barrier(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, bus_size_t length, int flags);

🎀 read a whole region 🗺️

void
bus_space_read_region_1(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint8_t *datap,
    bus_size_t count);

void
bus_space_read_region_2(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint16_t *datap,
    bus_size_t count);

void
bus_space_read_region_4(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint32_t *datap,
    bus_size_t count);

void
bus_space_read_region_8(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint64_t *datap,
    bus_size_t count);

🎀 read a whole region, streaming 🗺️🌊

void
bus_space_read_region_stream_1(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint8_t *datap,
    bus_size_t count);

void
bus_space_read_region_stream_2(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint16_t *datap,
    bus_size_t count);

void
bus_space_read_region_stream_4(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint32_t *datap,
    bus_size_t count);

void
bus_space_read_region_stream_8(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint64_t *datap,
    bus_size_t count);

🎀 write a whole region 🖊️

void
bus_space_write_region_1(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint8_t *datap,
    bus_size_t count);

void
bus_space_write_region_2(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint16_t *datap,
    bus_size_t count);

void
bus_space_write_region_4(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint32_t *datap,
    bus_size_t count);

void
bus_space_write_region_8(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint64_t *datap,
    bus_size_t count);

🎀 write a whole region, streaming 🖊️🌊

void
bus_space_write_region_stream_1(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint8_t *datap,
    bus_size_t count);

void
bus_space_write_region_stream_2(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint16_t *datap,
    bus_size_t count);

void
bus_space_write_region_stream_4(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint32_t *datap,
    bus_size_t count);

void
bus_space_write_region_stream_8(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint64_t *datap,
    bus_size_t count);

🎀 copy a region (src ➡️ dst, iconic behaviour)

void
bus_space_copy_region_1(bus_space_tag_t space,
    bus_space_handle_t srchandle, bus_size_t srcoffset,
    bus_space_handle_t dsthandle, bus_size_t dstoffset,
    bus_size_t count);

void
bus_space_copy_region_2(bus_space_tag_t space,
    bus_space_handle_t srchandle, bus_size_t srcoffset,
    bus_space_handle_t dsthandle, bus_size_t dstoffset,
    bus_size_t count);

void
bus_space_copy_region_4(bus_space_tag_t space,
    bus_space_handle_t srchandle, bus_size_t srcoffset,
    bus_space_handle_t dsthandle, bus_size_t dstoffset,
    bus_size_t count);

void
bus_space_copy_region_8(bus_space_tag_t space,
    bus_space_handle_t srchandle, bus_size_t srcoffset,
    bus_space_handle_t dsthandle, bus_size_t dstoffset,
    bus_size_t count);

🎀 copy a region, streaming 🚚🌊

void
bus_space_copy_region_stream_1(bus_space_tag_t space,
    bus_space_handle_t srchandle, bus_size_t srcoffset,
    bus_space_handle_t dsthandle, bus_size_t dstoffset,
    bus_size_t count);

void
bus_space_copy_region_stream_2(bus_space_tag_t space,
    bus_space_handle_t srchandle, bus_size_t srcoffset,
    bus_space_handle_t dsthandle, bus_size_t dstoffset,
    bus_size_t count);

void
bus_space_copy_region_stream_4(bus_space_tag_t space,
    bus_space_handle_t srchandle, bus_size_t srcoffset,
    bus_space_handle_t dsthandle, bus_size_t dstoffset,
    bus_size_t count);

void
bus_space_copy_region_stream_8(bus_space_tag_t space,
    bus_space_handle_t srchandle, bus_size_t srcoffset,
    bus_space_handle_t dsthandle, bus_size_t dstoffset,
    bus_size_t count);

🎀 set a region (fill it with the same value, lowkey satisfying)

void
bus_space_set_region_1(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint8_t value, bus_size_t count);

void
bus_space_set_region_2(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint16_t value, bus_size_t count);

void
bus_space_set_region_4(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint32_t value, bus_size_t count);

void
bus_space_set_region_8(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint64_t value, bus_size_t count);

and that's where we're at so far, bestie 🧚💜 — the synopsis keeps going, and there's the whole DESCRIPTION to get to, so stay with me

void
bus_space_set_region_stream_1(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint8_t value,
    bus_size_t count);

void
bus_space_set_region_stream_2(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint16_t value,
    bus_size_t count);

void
bus_space_set_region_stream_4(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint32_t value,
    bus_size_t count);

void
bus_space_set_region_stream_8(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint64_t value,
    bus_size_t count);

void
bus_space_read_multi_1(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint8_t *datap, bus_size_t count);

void
bus_space_read_multi_2(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint16_t *datap, bus_size_t count);

void
bus_space_read_multi_4(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint32_t *datap, bus_size_t count);

void
bus_space_read_multi_8(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint64_t *datap, bus_size_t count);

void
bus_space_read_multi_stream_1(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint8_t *datap,
    bus_size_t count);

void
bus_space_read_multi_stream_2(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint16_t *datap,
    bus_size_t count);

void
bus_space_read_multi_stream_4(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint32_t *datap,
    bus_size_t count);

void
bus_space_read_multi_stream_8(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint64_t *datap,
    bus_size_t count);

void
bus_space_write_multi_1(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint8_t *datap,
    bus_size_t count);

void
bus_space_write_multi_2(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint16_t *datap,
    bus_size_t count);

void
bus_space_write_multi_4(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint32_t *datap,
    bus_size_t count);

void
bus_space_write_multi_8(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint64_t *datap,
    bus_size_t count);

void
bus_space_write_multi_stream_1(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint8_t *datap,
    bus_size_t count);

void
bus_space_write_multi_stream_2(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint16_t *datap,
    bus_size_t count);

void
bus_space_write_multi_stream_4(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint32_t *datap,
    bus_size_t count);

void
bus_space_write_multi_stream_8(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint64_t *datap,
    bus_size_t count);

void
bus_space_set_multi_1(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint8_t value, bus_size_t count);

void
bus_space_set_multi_2(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint16_t value, bus_size_t count);

void
bus_space_set_multi_4(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint32_t value, bus_size_t count);

void
bus_space_set_multi_8(bus_space_tag_t space, bus_space_handle_t handle,
    bus_size_t offset, uint64_t value, bus_size_t count);

void
bus_space_set_multi_stream_1(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint8_t value,
    bus_size_t count);

void
bus_space_set_multi_stream_2(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint16_t value,
    bus_size_t count);

void
bus_space_set_multi_stream_4(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint32_t value,
    bus_size_t count);

void
bus_space_set_multi_stream_8(bus_space_tag_t space,
    bus_space_handle_t handle, bus_size_t offset, uint64_t value,
    bus_size_t count);

💖 DESCRIPTION 💖

okay so bestie, here's the whole why of it: the bus_space functions exist so that device drivers can get at bus memory and register areas in a machine-independent way. no cap, that's the entire point. and every single function and type in this whole document? you get access to all of it just by including the <machine/bus.h> header file. that's it. one include. slay. ✨

here's the vibe of the problem 💅 — tons of common devices get used on multiple architectures, but the way you access them is different on each one, all because of architectural constraints. for instance (and this example is iconic), a device that's mapped in one system's I/O space might be mapped in memory space on a second system. and then on a third system, architectural limitations might change the way the registers need to be accessed (e.g. creating a non-linear register space 🙈). in some cases, a single driver may even need to access the same type of device in multiple different ways inside a single system or architecture. so the goal of the bus_space functions is twofold, and honestly both goals ate:

1. let a single driver source file manipulate a set of devices on different system architectures 🫶
2. let a single driver object file manipulate a set of devices on multiple bus types on a single architecture 🌈

now, not all buses have to implement every single function described in this document — though it's encouraged if the operations are logically supported by that bus. and any function that isn't implemented should cause compile-time errors if possible, which is genuinely so fair of them. 💀

all the interface definitions in this document are shown as function prototypes and discussed as if they were required to be actual functions. implementations are encouraged to implement prototyped (type-checked) versions of these interfaces, but honestly they may implement them as macros if that's appropriate. and listen — machine-dependent types, variables, and functions should be marked clearly in <machine/bus.h> so nobody gets them confused with the machine-independent types and functions, and if possible they should be given names which make the machine-dependence obvious. do that. it's giving consideration. 🎀

---

🦋 CONCEPTS AND GUIDELINES 🦋

bus spaces are described by bus space tags, and here's the tea: those can only be created by machine-dependent code. periodt. a given machine may have several different types of bus space (e.g. memory space and I/O space), and so it may provide multiple different bus space tags. individual buses or devices on a machine may use more than one bus space tag — for instance, ISA devices are given an ISA memory space tag and an ISA I/O space tag. and architectures may have several different tags that represent the same type of space, for instance because of multiple different host bus interface chipsets. lowkey iconic of them. 🌸

a range in bus space is described by a bus address and a bus size. the bus address describes the start of the range in bus space; the bus size describes the size of the range in bytes. buses that aren't byte addressable may require you to use bus space ranges with appropriately aligned addresses and properly rounded sizes — so check yourself before you wreck yourself on alignment. 🧚

access to regions of bus space is facilitated by bus space handles, which are usually created by mapping a specific range of a bus space. handles may also be created by allocating and mapping a range of bus space, where the actual location is picked by the implementation, within bounds specified by whoever called the allocation function. main character energy: the implementation chooses. 😌

all of the bus space access functions require one bus space tag argument, at least one handle argument, and at least one offset argument (a bus size). the bus space tag specifies the space, each handle specifies a region in that space, and each offset specifies the offset into the region where the actual location(s) to be accessed live. offsets are given in bytes, though buses may impose alignment constraints. crucially 🔥: the offset used to access data relative to a given handle must be such that all of the data being accessed is inside the mapped region that the handle describes. trying to access data outside that region? that's an error. not a vibe. 🚫

okay so here's the buffering thing, and it's kind of the moment. because some architectures' memory systems use buffering to improve memory and device access performance, there's a mechanism you can use to create “barriers” in the bus space read and write stream. there are three types of barriers: read, write, and read/write. the rules, crystal clear:

• all reads started to the region before a read barrier must complete before any reads after the read barrier are started 🫶
• the analogous requirement is true for write barriers ✨
• read/write barriers force all reads and writes started before the barrier to complete before any reads or writes after the barrier are started 🔥

correctly-written drivers will include all appropriate barriers, and will assume only the read/write ordering imposed by the barrier operations. that's it. don't assume extra. ngl that's the whole assignment. 💅

if you're trying to write portable drivers with the bus_space functions, bestie, please try to make minimal assumptions about what the system allows. specifically, you should expect that:

• the system requires bus space addresses being accessed to be naturally aligned (i.e., the base address of the handle added to the offset is a multiple of the access size) 🎀
• the system does alignment checking on pointers (i.e., the pointer to the objects being read and written must point to properly-aligned data) ⭐

⚠️ big warning energy, read this twice: the descriptions of the bus_space functions given below all assume they're called with proper arguments. if they're called with invalid arguments, or arguments that are out of range (e.g. trying to access data outside of the region mapped when a given handle was created), undefined behaviour results. in that case they may cause the system to halt — either intentionally (via panic) or unintentionally (by causing a fatal trap or by some other means) — or they may cause improper operation which is not immediately fatal. 💀

functions which return void, or which return data read from bus space (i.e., functions which do not obviously return an error code), do not fail. they could only fail if given invalid arguments — and in that case their behaviour is undefined. and one more: functions which take a count of bytes have undefined results if the specified count is zero. zero. don't do it. 🍓

✨ TYPES ✨

okay so bestie, <machine/bus.h> is where these types live, and they're literally the little cast of characters that makes the bus_space functions usable by drivers. 🫶 Let's meet them:

🌸 bus_addr_t

The bus_addr_t type describes bus addresses. It must be an unsigned integral type capable of holding the largest bus address usable by the architecture. This type is primarily used when mapping and unmapping bus space. 💖

🎀 bus_size_t

The bus_size_t type describes sizes of ranges in bus space. It must be an unsigned integral type capable of holding the size of the largest bus address range usable on the architecture. This type is used by virtually all of the bus_space functions, describing sizes when mapping regions and offsets into regions when performing space access operations. no cap, it's everywhere. ✨

🦋 bus_space_tag_t

The bus_space_tag_t type describes a particular bus space on a machine. Its contents are machine-dependent and should be considered opaque by machine-independent code. This type is used by all bus_space functions to name the space on which they're operating. 🫶

💜 bus_space_handle_t

The bus_space_handle_t type describes a mapping of a range of bus space. Its contents are machine-dependent and should be considered opaque by machine-independent code. This type is used when performing bus space access operations. 💅

---

🗺️ MAPPING AND UNMAPPING BUS SPACE 💖

This section is specific to the NetBSD version of these functions and may or may not apply to the FreeBSD version. 👀

Bus space must be mapped before it can be used, and should be unmapped when it is no longer needed. The bus_space_map() and bus_space_unmap() functions provide these capabilities. literally the entry and exit vibes. ✨

Some drivers need to be able to pass a subregion of already-mapped bus space to another driver or module within a driver. The bus_space_subregion() function allows such subregions to be created. it's giving helpful bestie energy. 🎀

💅 bus_space_map(space, address, size, flags, handlep)

The bus_space_map() function maps the region of bus space named by the space, address, and size arguments. If successful, it returns zero and fills in the bus space handle pointed to by handlep with the handle that can be used to access the mapped region. If unsuccessful, it will return non-zero and leave the bus space handle pointed to by handlep in an undefined state. 😭 undefined handle is not the vibe.

The flags argument controls how the space is to be mapped. Supported flags include:

• BUS_SPACE_MAP_CACHEABLE — Try to map the space so that accesses can be cached and/or prefetched by the system. If this flag is not specified, the implementation should map the space so that it will not be cached or prefetched. This flag must have a value of 1 on all implementations for backward compatibility. 🔥
• BUS_SPACE_MAP_LINEAR — Try to map the space so that its contents can be accessed linearly via normal memory access methods (e.g. pointer dereferencing and structure accesses). This is useful when software wants to do direct access to a memory device, e.g. a frame buffer. If this flag is specified and linear mapping is not possible, the bus_space_map() call should fail. If this flag is not specified, the system may map the space in whatever way is most convenient. 💫
• BUS_SPACE_MAP_NONPOSTED — Try to map the space using non-posted device memory. This is to support buses and devices where mapping with posted device memory is unsupported or broken. This flag is currently only available on arm64. 🧚

Not all combinations of flags make sense or are supported with all spaces. For instance, BUS_SPACE_MAP_CACHEABLE may be meaningless when used on many systems' I/O port spaces, and on some systems BUS_SPACE_MAP_LINEAR without BUS_SPACE_MAP_CACHEABLE may never work. When the system hardware or firmware provides hints as to how spaces should be mapped (e.g. the PCI memory mapping registers' “prefetchable” bit), those hints should be followed for maximum compatibility. On some systems, requesting a mapping that cannot be satisfied (e.g. requesting a non-cacheable mapping when the system can only provide a cacheable one) will cause the request to fail. 🙈

Some implementations may keep track of use of bus space for some or all bus spaces and refuse to allow duplicate allocations. This is encouraged for bus spaces which have no notion of slot-specific space addressing, such as ISA, and for spaces which coexist with those spaces (e.g. PCI memory and I/O spaces co-existing with ISA memory and I/O spaces). 👑

Mapped regions may contain areas for which there is no device on the bus. If space in those areas is accessed, the results are bus-dependent.

⚠️ bestie, that last bit means the hardware gets to decide what happens, and it might not be cute. no invented behaviour, okay? 💀

🎀 bus_space_unmap(space, handle, size)

The bus_space_unmap() function unmaps a region of bus space mapped with bus_space_map(). When unmapping a region, the size specified should be the same as the size given to bus_space_map() when mapping that region. matching sizes, periodt. ✨

After bus_space_unmap() is called on a handle, that handle is no longer valid. (If copies were made of the handle they are no longer valid, either.) 🫶

This function will never fail. If it would fail (e.g. because of an argument error), that indicates a software bug which should cause a panic. In that case, bus_space_unmap() will never return. 😭 so yeah, it's never-return levels of serious.

🦋 bus_space_subregion(space, handle, offset, size, nhandlep)

The bus_space_subregion() function is a convenience function which makes a new handle to some subregion of an already-mapped region of bus space. The subregion described by the new handle starts at byte offset offset into the region described by handle, with the size given by size, and must be wholly contained within the original region. 🎀

If successful, bus_space_subregion() returns zero and fills in the bus space handle pointed to by nhandlep. If unsuccessful, it returns non-zero and leaves the bus space handle pointed to by nhandlep in an undefined state. In either case, the handle described by handle remains valid and is unmodified. 💖

When done with a handle created by bus_space_subregion(), the handle should be thrown away. Under no circumstances should bus_space_unmap() be used on the handle. Doing so may confuse any resource management being done on the space, and will result in undefined behaviour. When bus_space_unmap() or bus_space_free() is called on a handle, all subregions of that handle become invalid. 🚨 literally do not do it, bestie.

---

🎀 ALLOCATING AND FREEING BUS SPACE 🎀

This section is specific to the NetBSD version of these functions and may or may not apply to the FreeBSD version. 👀

Some devices require or allow bus space to be allocated by the operating system for device use. When the devices no longer need the space, the operating system should free it for use by other devices. The bus_space_alloc() and bus_space_free() functions provide these capabilities. ✨

🛠️ bus_space_alloc(space, reg_start, reg_end, size, alignment, boundary, flags, addrp, handlep)

The bus_space_alloc() function allocates and maps a region of bus space with the size given by size, corresponding to the given constraints. If successful, it returns zero, fills in the bus address pointed to by addrp with the bus space address of the allocated region, and fills in the bus space handle pointed to by handlep with the handle that can be used to access that region. If unsuccessful, it returns non-zero and leaves the bus address pointed to by addrp and the bus space handle pointed to by handlep in an undefined state. 💫

Constraints on the allocation are given by the reg_start, reg_end, alignment, and boundary parameters. The allocated region will start at or after reg_start and end before or at reg_end. The alignment constraint must be a power of two, and the allocated region will start at an address that is an even multiple of that power of two. The boundary constraint, if non-zero, ensures that the region is allocated so that first address in region / boundary has the same value as last address in region / boundary. If the constraints cannot be met, bus_space_alloc() will fail. It is an error to specify a set of constraints that can never be met (for example, size greater than boundary). 😭 math said no.

The flags parameter is the same as the like-named parameter to bus_space_map(), the same flag values should be used, and they have the same meanings. 🫶

Handles created by bus_space_alloc() should only be freed with bus_space_free(). Trying to use bus_space_unmap() on them causes undefined behaviour. The bus_space_subregion() function can be used on handles created by bus_space_alloc(). 🚨 matching cleanup functions is the whole game.

🌈 bus_space_free(space, handle, size)

The bus_space_free() function unmaps and frees a region of bus space mapped and allocated with bus_space_alloc(). When unmapping a region, the size specified should be the same as the size given to bus_space_alloc() when allocating the region. ✨

After bus_space_free() is called on a handle, that handle is no longer valid. (If copies were made of the handle, they are no longer valid, either.) 💅

This function will never fail. If it would fail (e.g. because of an argument error), that indicates a software bug which should cause a panic. In that case, bus_space_free() will never return. 😭 and that's the free-handle tea.

✨ READING AND WRITING SINGLE DATA ITEMS ✨

Okay bestie, the absolute simplest way to touch bus space is to just read or write one single data item. That's it, that's the vibe. The bus_space_read_N() and bus_space_write_N() families give you the power to read and write 1, 2, 4, and 8 byte data items on buses that actually support those access sizes. 💅

---

bus_space_read_1(space, handle, offset)

bus_space_read_2(space, handle, offset)

bus_space_read_4(space, handle, offset)

bus_space_read_8(space, handle, offset)

The bus_space_read_N() family reads a 1, 2, 4, or 8 byte data item from the offset given by offset, into the region specified by handle, of the bus space specified by space. And like, the location you're reading has to lie within the bus space region that handle points at — no sneaking outside the region, bestie. 🙈

For portability, the starting address of the region specified by handle plus the offset should be a multiple of the size of the data item you're reading. On some systems, ignoring this requirement might get you incorrect data read back, and on others it could straight-up cause a system crash. 😭 So like... respect the alignment, fr fr.

Read operations done by the bus_space_read_N() functions may be executed out of order with respect to other pending read and write operations — unless order is enforced by using the bus_space_barrier() function. (More on that diva down below. 👀)

These functions will never fail. If they would fail (e.g. because of an argument error), that means there's a software bug, and that bug should cause a panic. In that case, they will never return. Periodt. 💀

---

bus_space_write_1(space, handle, offset, value)

bus_space_write_2(space, handle, offset, value)

bus_space_write_4(space, handle, offset, value)

bus_space_write_8(space, handle, offset, value)

The bus_space_write_N() family writes a 1, 2, 4, or 8 byte data item to the offset given by offset, into the region specified by handle, of the bus space specified by space. Same rule as before: the location being written must lie within the bus space region specified by handle. 🫶

For portability, the starting address of the region specified by handle plus the offset should be a multiple of the size of the data item being written. On some systems, not obeying this may cause incorrect data to be written, and on others it may cause a system crash. Not the slay we're going for. 💀

Write operations done by the bus_space_write_N() functions may be executed out of order with respect to other pending read and write operations — unless order is enforced by using the bus_space_barrier() function.

These functions will never fail. If they would fail (e.g. because of an argument error), that indicates a software bug which should cause a panic. In that case, they will never return. Iconic behaviour, honestly. 👑

---

🔍 PROBING BUS SPACE FOR HARDWARE WHICH MAY NOT RESPOND 🔍

Okay so here's the little problem with the bus_space_read_N() and bus_space_write_N() families: they give you zero protection against exceptions that can happen when no physical hardware or device actually responds to the read or write cycles. 😬 In that situation, the system would typically panic due to a kernel-mode bus error. Not cute.

The bus_space_peek_N() and bus_space_poke_N() family of functions exist to handle these exceptions gracefully, without the risk of crashing the whole system. 🧚✨

As with bus_space_read_N() and bus_space_write_N(), the peek and poke functions give you the ability to read and write 1, 2, 4, and 8 byte data items on busses which support those access sizes. And all of the constraints specified in the descriptions of the bus_space_read_N() and bus_space_write_N() functions also apply to bus_space_peek_N() and bus_space_poke_N(). No exceptions (well — no unhandled ones, anyway 😅).

Bonus: explicit calls to the bus_space_barrier() function are not required here, because the implementation will ensure all pending operations complete before the peek or poke operation starts. It'll also ensure that the peek or poke operations complete before returning. Convenient, right?? 💅

The return value tells you how the peek or poke went:

• A return value of zero implies that a hardware device is responding to the operation at the specified offset in the bus space.
• A non-zero return value indicates that the kernel intercepted a hardware exception (e.g., bus error) when the peek or poke operation was attempted.

Heads up bestie: some busses are simply incapable of generating exceptions when non-existent hardware is accessed. In those cases, these functions will always return zero, and the value of the data read by bus_space_peek_N() will be unspecified. 🫠

Finally, a lil note: at this time the bus_space_peek_N() and bus_space_poke_N() functions are not re-entrant, and therefore should not be used from within an interrupt service routine. This constraint may be removed at some point in the future. Fingers crossed. 🤞

---

bus_space_peek_1(space, handle, offset, datap)

bus_space_peek_2(space, handle, offset, datap)

bus_space_peek_4(space, handle, offset, datap)

bus_space_peek_8(space, handle, offset, datap)

The bus_space_peek_N() family cautiously reads a 1, 2, 4, or 8 byte data item from the offset specified by offset in the region specified by handle of the bus space specified by space. The data item that gets read is stored in the location pointed to by datap. And yes, it is permissible for datap to be NULL — in which case the data item gets discarded after being read. Bye bestie, didn't need you anyway. 💨

---

bus_space_poke_1(space, handle, offset, value)

bus_space_poke_2(space, handle, offset, value)

bus_space_poke_4(space, handle, offset, value)

bus_space_poke_8(space, handle, offset, value)

The bus_space_poke_N() family cautiously writes a 1, 2, 4, or 8 byte data item specified by value to the offset specified by offset in the region specified by handle of the bus space specified by space. Gentle poke. So polite. 🎀

---

🚧 BARRIERS 🚧

So here's the thing: to let high-performance buffering implementations avoid bus activity on every single operation, read and write ordering should be specified explicitly by drivers whenever it's necessary. The bus_space_barrier() function is literally exactly that ability. It's giving main character energy in this whole section. ⭐

---

bus_space_barrier(space, handle, offset, length, flags)

The bus_space_barrier() function enforces ordering of bus space read and write operations for the specified subregion (described by the offset and length parameters) of the region named by handle in the space named by space.

The flags argument controls what types of operations are going to be ordered. The supported flags are:

• BUS_SPACE_BARRIER_READ — Synchronize read operations.
• BUS_SPACE_BARRIER_WRITE — Synchronize write operations.

Those flags can be combined (or-ed together) to enforce ordering on both read and write operations. Two birds, one barrier. 🦋

All of the specified type(s) of operation which are done to the region before the barrier operation are guaranteed to complete before any of the specified type(s) of operation done after the barrier. No cutting in line, bestie. 💅

---

Example time! ✨ Consider a hypothetical device with two single-byte ports: one write-only input port (at offset 0) and a read-only output port (at offset 1). Operation of the device goes like this: data bytes are written to the input port, and the device places them on a stack, the top of which is read by reading from the output port. The correct sequence to write two data bytes to the device, then read those two data bytes back, would be:

/*
 * t and h are the tag and handle for the mapped device's
 * space.
 */
bus_space_write_1(t, h, 0, data0);
bus_space_barrier(t, h, 0, 1, BUS_SPACE_BARRIER_WRITE);  /* 1 */
bus_space_write_1(t, h, 0, data1);
bus_space_barrier(t, h, 0, 2,
    BUS_SPACE_BARRIER_READ|BUS_SPACE_BARRIER_WRITE);     /* 2 */
ndata1 = bus_space_read_1(t, h, 1);
bus_space_barrier(t, h, 1, 1, BUS_SPACE_BARRIER_READ);   /* 3 */
ndata0 = bus_space_read_1(t, h, 1);
/* data0 == ndata0, data1 == ndata1 */

Let me break down what each of those barriers is doing, because it's lowkey genius:

1. The first barrier makes sure that the first write finishes before the second write is issued — so the two writes to the input port happen in order and don't get collapsed into a single write. This ensures the data bytes are written to the device correctly and in order. 🔥
2. The second barrier makes sure that the writes to the output port finish before any of the reads to the input port are issued, which makes sure that all of the writes are finished before data gets read. This ensures the first byte read from the device really is the last one that was written. 🎯
3. The third barrier makes sure that the first read finishes before the second read is issued, ensuring that data is read correctly and in order. 💖

Also, the barriers in the example above are specified to cover the absolute minimum number of bus space locations. But it's totally correct (and often easier) to make barrier operations cover the device's whole range of bus space — that is, to specify an offset of 0 and the size of the whole region. Do less work, bestie. 🌸

🌸 REGION OPERATIONS 🌸

Okay bestie, so some devices use buffers that are mapped as regions in bus space, and drivers are constantly like "girl I need to copy the contents of those buffers to or from memory" — think into <pink>mbufs</pink> that get passed up to higher levels of the system, or from mbufs that are about to be output to a network. And because we want drivers to do this as efficiently as possible (main character energy only), the bus_space_read_region_N() and bus_space_write_region_N() families of functions exist. Slay. 💅

And sometimes drivers need to copy one region of bus space to another, or set every location in a region of bus space to a single value — for that we have the bus_space_copy_region_N() family and the bus_space_set_region_N() family. Iconic, honestly.

---

🎀 bus_space_read_region_1(space, handle, offset, datap, count)

🎀 bus_space_read_region_2(space, handle, offset, datap, count)

🎀 bus_space_read_region_4(space, handle, offset, datap, count)

🎀 bus_space_read_region_8(space, handle, offset, datap, count)

So the bus_space_read_region_N() family reads count 1, 2, 4, or 8 byte data items from bus space, starting at byte offset offset in the region specified by handle of the bus space specified by space, and writes them into the array specified by datap. Each successive data item is read from an offset 1, 2, 4, or 8 bytes after the previous data item (depending on which function you're using). And fr fr, all locations being read must lie within the bus space region specified by handle. No sneaking outside the region, bestie.

For portability, the starting address of the region specified by handle plus the offset should be a multiple of the size of the data items being read, and the data array pointer should be properly aligned. On some systems, not obeying these requirements may cause incorrect data to be read — and on others it may cause a system crash 😭. So like, please align your stuff.

Read operations done by the bus_space_read_region_N() functions may be executed in any order. They may also be executed out of order with respect to other pending read and write operations unless order is enforced by use of the bus_space_barrier() function. And ngl there is no way to insert barriers between reads of individual bus space locations executed by the bus_space_read_region_N() functions. That's just how it is. 🤷‍♀️

These functions will never fail. If they would fail (e.g. because of an argument error), that indicates a software bug which should cause a panic. In that case, they will never return. 💀

---

🦋 bus_space_write_region_1(space, handle, offset, datap, count)

🦋 bus_space_write_region_2(space, handle, offset, datap, count)

🦋 bus_space_write_region_4(space, handle, offset, datap, count)

🦋 bus_space_write_region_8(space, handle, offset, datap, count)

Now the bus_space_write_region_N() family — it reads count 1, 2, 4, or 8 byte data items from the array specified by datap and writes them to bus space, starting at byte offset offset in the region specified by handle of the bus space specified by space. Each successive data item is written to an offset 1, 2, 4, or 8 bytes after the previous data item (depending on which function is used). And again, all locations being written must lie within the bus space region specified by handle. Stay in your lane, data.

For portability, the starting address of the region specified by handle plus the offset should be a multiple of the size of the data items being written, and the data array pointer should be properly aligned. On some systems, not obeying these requirements may cause incorrect data to be written, and on others it may cause a system crash. Same deal as before, just the write-flavored version. 🙈

Write operations done by the bus_space_write_region_N() functions may be executed in any order. They may also be executed out of order with respect to other pending read and write operations unless order is enforced by use of the bus_space_barrier() function. And there is no way to insert barriers between writes of individual bus space locations executed by the bus_space_write_region_N() functions. Periodt. ✨

These functions will never fail. If they would fail (e.g. because of an argument error), that indicates a software bug which should cause a panic. In that case, they will never return. 💀

---

🧚 bus_space_copy_region_1(space, srchandle, srcoffset, dsthandle, dstoffset, count)

🧚 bus_space_copy_region_2(space, srchandle, srcoffset, dsthandle, dstoffset, count)

🧚 bus_space_copy_region_4(space, srchandle, srcoffset, dsthandle, dstoffset, count)

🧚 bus_space_copy_region_8(space, srchandle, srcoffset, dsthandle, dstoffset, count)

The bus_space_copy_region_N() family copies count 1, 2, 4, or 8 byte data items in bus space from the area starting at byte offset srcoffset in the region specified by srchandle of the bus space specified by space, to the area starting at byte offset dstoffset in the region specified by dsthandle in the same bus space. Each successive data item read or written has an offset 1, 2, 4, or 8 bytes after the previous data item (depending on which function is used). And all locations being read and written must lie within the bus space region specified by their respective handles — both of them, no exceptions, bestie. 🫶

For portability, the starting addresses of the regions specified by each handle plus its respective offset should be a multiple of the size of the data items being copied. On some systems, not obeying this requirement may cause incorrect data to be copied, and on others it may cause a system crash. So keep it aligned, iykyk.

Read and write operations done by the bus_space_copy_region_N() functions may be executed in any order. They may also be executed out of order with respect to other pending read and write operations unless order is enforced by use of the bus_space_barrier() function. And there is no way to insert barriers between reads or writes of individual bus space locations executed by the bus_space_copy_region_N() functions. That's the vibe check, and it failed. 🌈

Little bonus fact that's lowkey amazing: overlapping copies between different subregions of a single region of bus space are handled correctly by the bus_space_copy_region_N() functions. The copy functions ate and left no crumbs. 👑

These functions will never fail. If they would fail (e.g. because of an argument error), that indicates a software bug which should cause a panic. In that case, they will never return. 💀

---

🍓 bus_space_set_region_1(space, handle, offset, value, count)

🍓 bus_space_set_region_2(space, handle, offset, value, count)

🍓 bus_space_set_region_4(space, handle, offset, value, count)

🍓 bus_space_set_region_8(space, handle, offset, value, count)

Last but not least, the bus_space_set_region_N() family writes the given value to count 1, 2, 4, or 8 byte data items in bus space, starting at byte offset offset in the region specified by handle of the bus space specified by space. Each successive data item has an offset 1, 2, 4, or 8 bytes after the previous data item (depending on which function is used). And yeah, all locations being written must lie within the bus space region specified by handle. Same rule as always, girl.

For portability, the starting address of the region specified by handle plus the offset should be a multiple of the size of the data items being written. On some systems, not obeying this requirement may cause incorrect data to be written, and on others it may cause a system crash. We've been over this and yet here we are. 😭

Write operations done by the bus_space_set_region_N() functions may be executed in any order. They may also be executed out of order with respect to other pending read and write operations unless order is enforced by use of the bus_space_barrier() function. And there is no way to insert barriers between writes of individual bus space locations executed by the bus_space_set_region_N() functions. No cap. 💜

These functions will never fail. If they would fail (e.g. because of an argument error), that indicates a software bug which should cause a panic. In that case, they will never return. 💀

🌀 READING AND WRITING A SINGLE LOCATION MULTIPLE TIMES 🌀

okay so picture this: some devices have a single spot in bus space that you gotta read or write over and over to move data around — like the packet buffer FIFOs on some ethernet devices, bestie. total "same address, different day" energy. so that drivers can handle these devices as efficiently as possible, we got the bus_space_read_multi_N(), bus_space_set_multi_N(), and bus_space_write_multi_N() function families. iconic behavior honestly 💅

bus_space_read_multi_1(space, handle, offset, datap, count) ⭐

bus_space_read_multi_2(space, handle, offset, datap, count) ⭐

bus_space_read_multi_4(space, handle, offset, datap, count) ⭐

bus_space_read_multi_8(space, handle, offset, datap, count) ⭐

the bus_space_read_multi_N() family reads count 1, 2, 4, or 8 byte data items from bus space at byte offset offset in the region specified by handle of the bus space specified by space, and writes them into the array specified by datap. every successive data item comes from the same location in bus space. and the location being read has to lie within the bus space region specified by handle, no exceptions 🫶

for portability, the starting address of the region specified by handle plus the offset should be a multiple of the size of the data items being read, and the data array pointer should be properly aligned. on some systems, not obeying these requirements may cause incorrect data to be read; on others it may cause a system crash. so like… maybe just align it, bestie 😭

read operations done by the bus_space_read_multi_N() functions may be executed out of order with respect to other pending read and write operations unless order is enforced by use of the bus_space_barrier() function. and because the bus_space_read_multi_N() functions read the same bus space location multiple times, they place an implicit read barrier between each successive read of that bus space location. love that for them ✨

these functions will never fail. if they would fail (e.g. because of an argument error), that indicates a software bug which should cause a panic. in that case, they will never return. periodt 💀

bus_space_write_multi_1(space, handle, offset, datap, count) 🔥

bus_space_write_multi_2(space, handle, offset, datap, count) 🔥

bus_space_write_multi_4(space, handle, offset, datap, count) 🔥

bus_space_write_multi_8(space, handle, offset, datap, count) 🔥

the bus_space_write_multi_N() family of functions reads count 1, 2, 4, or 8 byte data items from the array specified by datap and writes them into bus space at byte offset offset in the region specified by handle of the bus space specified by space. every successive data item gets written to the same location in bus space. and the location being written must lie within the bus space region specified by handle 👑

for portability, the starting address of the region specified by handle plus the offset should be a multiple of the size of the data items being written, and the data array pointer should be properly aligned. on some systems, not obeying these requirements may cause incorrect data to be written; on others it may cause a system crash. same warning, same vibe, still real 🙈

write operations done by the bus_space_write_multi_N() functions may be executed out of order with respect to other pending read and write operations unless order is enforced by use of the bus_space_barrier() function. and because the bus_space_write_multi_N() functions write the same bus space location multiple times, they place an implicit write barrier between each successive write of that bus space location 🌸

these functions will never fail. if they would fail (e.g. because of an argument error), that indicates a software bug which should cause a panic. in that case, they will never return. no cap 💅

bus_space_set_multi_1(space, handle, offset, value, count) 🎀

bus_space_set_multi_2(space, handle, offset, value, count) 🎀

bus_space_set_multi_4(space, handle, offset, value, count) 🎀

bus_space_set_multi_8(space, handle, offset, value, count) 🎀

the bus_space_set_multi_N() writes value into bus space at byte offset offset in the region specified by handle of the bus space specified by space, count times. same spot, count times, it's giving "stamp it repeatedly". the location being written must lie within the bus space region specified by handle 🦋

for portability, the starting address of the region specified by handle plus the offset should be a multiple of the size of the data items being written, and the data array pointer should be properly aligned. on some systems, not obeying these requirements may cause incorrect data to be written; on others it may cause a system crash ⚠️

write operations done by the bus_space_set_multi_N() functions may be executed out of order with respect to other pending read and write operations unless order is enforced by use of the bus_space_barrier() function. and because the bus_space_set_multi_N() functions write the same bus space location multiple times, they place an implicit write barrier between each successive write of that bus space location 🌈

these functions will never fail. if they would fail (e.g. because of an argument error), that indicates a software bug which should cause a panic. in that case, they will never return. fr fr 💜

---

🌊 STREAM FUNCTIONS 🌊

okay so most of the bus_space functions assume a host byte-order and a bus byte-order and handle all the translation for the caller. but sometimes hardware maps a FIFO or some other memory region where the caller wants multi-word access that is untranslated. for those memory regions, you use the bus_space_*_stream_N() functions, bestie 🧚

bus_space_read_stream_1()
bus_space_read_stream_2()
bus_space_read_stream_4()
bus_space_read_stream_8()
bus_space_read_multi_stream_1()
bus_space_read_multi_stream_2()
bus_space_read_multi_stream_4()
bus_space_read_multi_stream_8()
bus_space_read_region_stream_1()
bus_space_read_region_stream_2()
bus_space_read_region_stream_4()
bus_space_read_region_stream_8()
bus_space_write_stream_1()
bus_space_write_stream_2()
bus_space_write_stream_4()
bus_space_write_stream_8()
bus_space_write_multi_stream_1()
bus_space_write_multi_stream_2()
bus_space_write_multi_stream_4()
bus_space_write_multi_stream_8()
bus_space_write_region_stream_1()
bus_space_write_region_stream_2()
bus_space_write_region_stream_4()
bus_space_write_region_stream_8()
bus_space_copy_region_stream_1()
bus_space_copy_region_stream_2()
bus_space_copy_region_stream_4()
bus_space_copy_region_stream_8()
bus_space_set_multi_stream_1()
bus_space_set_multi_stream_2()
bus_space_set_multi_stream_4()
bus_space_set_multi_stream_8()
bus_space_set_region_stream_1()
bus_space_set_region_stream_2()
bus_space_set_region_stream_4()
bus_space_set_region_stream_8()

these functions are defined exactly like their non-stream counterparts, except they provide no byte-order translation. that's it, that's the whole difference — the _stream_ suffix is the main character here 👑

---

💫 COMPATIBILITY 💫

so the current NetBSD version of the bus_space interface specification differs slightly from the original spec that came into wide use and that FreeBSD adopted. a few of the function names and arguments have changed for consistency and increased functionality. glow-up era ✨

---

👀 SEE ALSO 👀

• bus_dma(9)

---

📜 HISTORY 📜

the bus_space functions were introduced in a different form (memory and I/O spaces were accessed via different sets of functions) in NetBSD 1.2. then the functions were merged to work on generic “spaces” early in the NetBSD 1.3 development cycle, and many drivers were converted to use them. this document was written later during the NetBSD 1.3 development cycle, and the specification was updated to fix some consistency problems and to add some missing functionality 🎀

the manual page was then adapted to the version of the interface that FreeBSD imported for the CAM SCSI drivers, plus subsequent evolution. the FreeBSD bus_space version was imported in FreeBSD 3.0. whole timeline arc fr fr 💖

---

🫶 AUTHORS 🫶

the bus_space interfaces were designed and implemented by the NetBSD developer community. primary contributors and implementors were Chris Demetriou, Jason Thorpe, and Charles Hannum, but the rest of the NetBSD developers and the user community played a significant role in development. it takes a village, and the village ate 🌸

Justin Gibbs ported these interfaces to FreeBSD.

Chris Demetriou wrote this manual page.

Warner Losh modified it for the FreeBSD implementation 👑

---

💀 BUGS 💀

this manual may not completely and accurately document the interface, and many parts of the interface are unspecified. so like… read it, love it, but don't treat it as the whole truth, bestie 😭

---

and that's a wrap on BUS_SPACE(9)!! this page comes from the Debian crew, dated May 1, 2021 — the source/version line and date, served fresh at the bottom of the manpage, just for you 🎀✨ go forth and map some bus space, icon 💅