[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[BOOTLOADER SPECIFICATION RFC] The bootloader log format for TrenchBoot
[BOOTLOADER SPECIFICATION RFC] The bootloader log format for TrenchBoot and others
Fri, 29 May 2020 13:27:35 +0200
Below you can find my rough idea of the bootloader log format which is
generic thing but initially will be used for TrenchBoot work. I discussed
this proposal with Ross and Daniel S. So, the idea went through initial
sanitization. Now I would like to take feedback from other folks too.
So, please take a look and complain...
In general we want to pass the messages produced by the bootloader to the OS
kernel and finally to the userspace for further processing and analysis. Below
is the description of the structures which will be used for this thing.
The members of struct bootloader_log:
- version: the bootloader log format version number, 1 for now,
- producer: the producer/bootloader type; we can steal some values from
- size: total size of the log buffer including the bootloader_log struct,
- next_off: offset in bytes, from start of the bootloader_log struct,
of the next byte after the last log message in the msgs;
i.e. the offset of the next available log message slot,
- msgs: the array of log messages.
The members of struct bootloader_log_msgs:
- level: similar to syslog meaning; can be used to differentiate
normal messages from debug messages; exact interpretation depends
on the current producer/bootloader type specified in the
- facility: similar to syslog meaning; can be used to differentiate
the sources of the messages, e.g. message produced by networking
module; exact interpretation depends on the current producer/bootloader
type specified in the bootloader_log.producer,
- type: similar to the facility member but NUL terminated string instead of
this will be used by GRUB for messages printed using grub_dprintf(),
- msg: the bootloader log message, NUL terminated string.
Note: The bootloaders are free to use/ignore any given set of level,
facility and/or type members. Though the usage of these members
has to be clearly defined. Ignored integer members should be set
to 0. Ignored type member should contain an empty NUL terminated
string. msg member is mandatory but can be an empty NUL terminated
Taking into account  and  I want to make this functionality generic
as much as possible. So, this bootloader log can be used with any bootloader
and OS kernel. However, initially the functionality will be implemented for
the Linux kernel and its boot protocol.
In case of Linux kernel the pointer to the bootloader_log struct should
be passed from the bootloader to the kernel through the boot_params and
the bootloader_log struct contents should be exposed via sysfs. E.g.
somewhere at /sys/kernel/debug or /sys/kernel/tracing or maybe we should
create new /sys/bootloader/log node.
If everybody is OK with this rough proposal then I will start working
on making it a part of Multiboot2 specification (the text above is just
raw description of the idea; it is not final text which land into the
spec). If you see better place for this thing just drop me a line.
- [BOOTLOADER SPECIFICATION RFC] The bootloader log format for TrenchBoot and others,
Daniel Kiper <=