Library Extensions

Optional companion libraries and output serializers for lazybios.

JSON Serialization

The JSON support provides cJSON-based serialization for parsed SMBIOS entry points and structure tables. It converts parsed lazybios structures into structured JSON trees.

JSON serialization is built into the library and always available.

API Overview

• lazybiosExtJSONAddSMBIOSInfo serializes entry-point metadata under the smbios_info key, including the SMBIOS version the firmware reported. The lazybios version itself is written at the root as lazybios_version, since it describes the tool rather than the machine.
• lazybiosExtJSONAddType0 through lazybiosExtJSONAddType46 serialize every standard SMBIOS type currently implemented by lazybios. Each function attaches its result under the matching TypeN key.
• The lazybiosExtJSONAddOem* functions serialize the vendor-specific structures. Because OEM structure numbers are only meaningful together with their vendor, these attach under a vendor-qualified key such as DellType212 rather than a bare TypeN.
• lazybiosParseJSONAll does the whole job in one call: it parses every implemented type into the context, then runs every serializer above against the caller's root. It is the JSON counterpart to lazybiosParseAll and inherits its behavior, so types already parsed are reused rather than re-parsed.

cJSON* root = cJSON_CreateObject();
if (lazybiosParseJSONAll(ctx, root) == 0) {
    char* text = cJSON_Print(root);
    puts(text);
    free(text);
}
cJSON_Delete(root);

Supported structures

JSON serialization supports all standard structures parsed by the library:

Types	Structures
0-4	BIOS, System, Baseboard, Chassis, and Processor Information
5-6	Legacy Memory Controller and Memory Module Information
7-14	Cache, Port Connector, System Slots, On Board Devices, OEM Strings, System Configuration Options, Firmware Language, and Group Associations
15-21	System Event Log, Physical Memory Array, Memory Device, 32-Bit Memory Error, Memory Array Mapped Address, Memory Device Mapped Address, and Built-in Pointing Device
22-29	Portable Battery, System Reset, Hardware Security, System Power Controls, Voltage Probe, Cooling Device, Temperature Probe, and Electrical Current Probe
30-39	Out-of-Band Remote Access, Boot Integrity Services, System Boot, 64-Bit Memory Error, Management Device, Management Device Component, Management Device Threshold Data, Memory Channel, IPMI Device, and System Power Supply
40-46	Additional Information, Onboard Devices Extended Information, Management Controller Host Interface, TPM Device, Processor Additional Information, Firmware Inventory Information, and String Property

OEM structures nest under oem, mirroring ctx->oem->dell->TypeN:

Key	Structure	Serializer
oem.dell.Type177	Dell BIOS Flags	lazybiosExtJSONAddOemDellType177
oem.dell.Type212	Dell Indexed I/O Access	lazybiosExtJSONAddOemDellType212
oem.dell.Type218	Dell Token Interface	lazybiosExtJSONAddOemDellType218
oem.hp.Type204	HPE ProLiant System/Rack Locator	lazybiosExtJSONAddOemHpType204

The detailed function documentation in lazybios_json.h covers the matching serializer for every type.

Output contract

Each serializer takes the result set returned by its getter and adds one child to the caller-owned cJSON root; call cJSON_Delete() on the root when finished. Parsed lazybios data must remain alive until the serializer returns. The serializers copy their output into cJSON, so the resulting cJSON tree remains valid after lazybiosCleanup().

Each TypeN key holds an array of record objects, an empty array when the table contains no structure of that type, or null when the serialiser was handed a NULL set. The value is never a string, so a consumer can iterate it without a type check.

Values that are address-like or bit-oriented — I/O ports, masks, indices, and token fields in the OEM structures — are written as hexadecimal strings such as "0x00B2" rather than as JSON numbers, matching how the library already serializes handles and identifiers. Quantities remain JSON numbers.

Every serialized record carries handle — the SMBIOS handle other structures reference it by — and length, the structure length the firmware reported.

Within a record the top-level members are the raw encodings, and their decoded forms sit in a nested decoded object:

{ "handle": "0x0400", "processor_type": 3,
  "decoded": { "processor_type": "Central Processor" } }

Field status handling:

• LAZYBIOS_FIELD_PRESENT values are serialized as native JSON strings or numbers.
• LAZYBIOS_FIELD_ABSENT and LAZYBIOS_FIELD_UNREACHABLE fields are null. Earlier releases wrote the sentinel string "N/A" for unreachable fields, which made a numeric member change type; length now carries the information needed to tell a short structure from an unpopulated field.

See also

Library Extensions