// internals

Development

Working on Visor itself.

Ground rules

• Zero warnings on both make and make ARCH=aarch64.
• No floating point / libm — Q16 fixed-point for anything fractional.
• RELATIVE-only relocations — verify with readelf -r after every change (see Building).
• ASCII-only UI text — the baked font covers ASCII.
• AArch64 strict alignment — read packed/foreign structures (device-path nodes, GPT entries, PE headers) via CopyMem into local variables, never by casting pointers.
• Comment-free sources — the codebase intentionally carries no comments; names and structure do the explaining. boot.conf.example is the exception (it is user documentation).
• Log every fallible step — one efi_log() line per decision or failure. Future-you debugging a stranger's laptop will be grateful.

How to add a config key

Example: a global key myfeature=1 with a per-entry override.

1. Declare it. Add int myfeature; to config_t in src/include/config.h (or to boot_entry_t in src/include/gui.h for an entry key).
2. Default it. Set the default in config_parse() in src/config.c (globals) and in config_add_entry() (entry fields — every field is initialized there).
3. Parse it. Globals: add a branch in apply_global() in src/config.c — that function receives each key/value pair, and theme files flow through the same path so themes can override it. Entry keys: the entry-block parser in the same file.
4. Use it. Read config->myfeature (wired through main.c into gui_state_t if the GUI needs it — see how mouse or hotplug travel).
5. Document it. Add a commented block to boot.conf.example and a row to the README/Configuration tables.
6. Verify. Clean build on both arches and the relocation check.

Testing changes

• Config parser: visor config validate against crafted configs.
• Real hardware is the final word — firmware quirks (relocations, GetInfo lies, LoadImage behavior, USB enumeration) only show up there. Keep boot.log from every test.

Anatomy of a boot entry

boot_entry_t (src/include/gui.h) is the central type: linked list, display fields (name, icon, color), boot fields (kernel, initrd, cmdline, uuid pin), security fields (sha256, encrypted flags, LUKS settings), plus deployments (OSTree), snapshots, and the hotplug volume pin. It flows from config.c (parser/detector) through gui.c (display/selection) into linux_boot.c (boot). If you extend it, initialize the field in config_add_entry() and free it in config_free() (and hp_free_entry() if hotplug entries can carry it).

Contributing

• Repo: github.com/IO-ZetZor/Visor-BootManager — issues and PRs welcome.
• Keep PRs single-purpose; include the boot.log of a real-hardware test where relevant.
• License is BSD 2-Clause; contributions are accepted under the same terms.