[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [BOOTLOADER SPECIFICATION RFC] The bootloader log format for TrenchBoot and others
Hey, 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. struct bootloader_log_msgs { grub_uint32_t level; grub_uint32_t facility; char type[]; char msg[]; } struct bootloader_log { grub_uint32_t version; grub_uint32_t producer; grub_uint32_t size; grub_uint32_t next_off; bootloader_log_msgs msgs[]; } 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 linux/Documentation/x86/boot.rst:type_of_loader, - 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 bootloader_log.producer, - 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 integer; 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 string. Taking into account [1] and [2] 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. Daniel [1] https://lists.gnu.org/archive/html/grub-devel/2019-10/msg00107.html [2] https://lists.gnu.org/archive/html/grub-devel/2019-11/msg00079.html
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |