Platform Notes and Limitations

Supported backends, implemented structure types, and API boundaries.

Platform status

• Linux host loading prefers sysfs, then searches /dev/mem from an address reported by /sys/firmware/efi/systab, or from the legacy firmware window.
• Windows host loading uses GetSystemFirmwareTable and a generated entry point.
• macOS host loading reads SMBIOS-EPS and SMBIOS from the AppleSMBIOS I/O Registry service using IOKit and CoreFoundation.
• OpenBSD host loading uses /var/run/dmesg.boot as an address hint before falling back to the legacy /dev/mem firmware window.
• FreeBSD host loading uses the hint.smbios.0.mem kernel environment value before falling back to the legacy /dev/mem firmware window. Its derivatives select the same backend and carry the same caveat.
• DragonFly BSD host loading uses the hint.smbios.0.mem kernel environment value before falling back to the legacy /dev/mem firmware window.
• NetBSD host loading uses machdep.smbios with the address-based /dev/smbios aperture, then /dev/mem; x86 additionally retains the legacy firmware-window scan.
• SunOS (Solaris/illumos) host loading prefers its offset-based /dev/smbios snapshot, then falls back to scanning the legacy firmware window through /dev/mem.
• Haiku and BeOS host loading scans only the legacy x86 firmware window through /dev/misc/mem or /dev/mem. A failed mapping is retried with pread, then lseek and read.
• QNX Neutrino host loading maps the legacy x86 firmware window with mmap_device_memory(), which needs the PROCMGR_AID_MEM_PHYS ability. Without it the backend falls back to /dev/mem. AArch64 targets have no legacy window and fail cleanly.
• MINIX 3 host loading scans only the legacy x86 firmware window through /dev/mem, with the same mapping and positional-read fallbacks as Haiku and BeOS.
• All /dev/mem paths remain subject to platform permissions, securelevel, and physical-memory access policy.
• LAZYBIOS_BACKEND_GENERIC assumes an unrecognized POSIX-like x86 target with /dev/mem or /dev/misc/mem; non-x86 targets fail cleanly instead of scanning the legacy address range. It is not a universal backend for unknown operating systems or architectures.
• The file input modes of lazybiosInit remain independent of host backend selection and need no privileges. Merged files may contain either a tightly concatenated table or a valid embedded table offset.

Implemented structures

The implemented high-level structure parsers are listed under SMBIOS Structure APIs. A public SMBIOS type identifier can exist for traversal or counting without implying that a matching high-level parser is available.

Result cardinality

Every getter returns a result set: an entries array with its count. There is no single-structure variant and no in-place population — a getter takes only the raw table and allocates what it returns.

A non-NULL set whose count is zero means the table contains no structure of that type, which is an ordinary outcome rather than a failure. NULL is reserved for unusable arguments or a failed allocation.

Raw representation

Entry-point structures and many raw fields intentionally retain their SMBIOS representation. The API does not normalize all sizes, identifiers, handles, or version-specific alternatives into a single schema. The decoded member carries the interpreted form where one exists; consult the relevant type guide for the fields where the raw encoding still matters.

Lifetime boundaries

Result sets returned by getters are allocated and are released either by lazybiosCleanup, when assigned to their context member, or by the matching lazybiosFreeType* function.

Inside a parsed record, string members fall into two groups. Those that reproduce a string the firmware wrote point into the context-owned DMI table; those in decoded are either static text or owned by the record and released with it. Either way, no string member is separately freeable. Pointers in the entry union refer to context-owned entry data. See Core Concepts and Ownership for the complete ownership model.

Type index validity

The cached type index in lazybiosDMI_t describes the exact dmi_data buffer it was built from. Replacing that buffer on an existing container without clearing index_valid leaves stale offsets behind. Code that assembles a lazybiosDMI_t by hand rather than through lazybiosInit should leave index_valid at zero and let the parsers walk the table.