[systemd-devel] bootloader time on a non-EFI bootloader

[Kay Sievers]

On Thu, Apr 9, 2015 at 11:28 AM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Mon, 16.03.15 11:29, Umut Tezduyar Lindskog (umut at tezduyar.com) wrote:
>>
>> I would like to pass the time it was spent in bootloader to systemd.
>> Is there a kernel command line to pass this information on non EFI
>> bootloader? Or is there an another way?
>
> I am open to add this, but I really don't want to see tons of
> different "drivers" to read this data added to systemd.

Right, mis-using the kernel command line does not look like an option
for support in systemd.

> Hence the way
> I think this should work, is adding a generic interface to the kernel
> to /sys/firmware/timing or so, where this information can be read
> from. We'd then make systemd read that. And wherever the information
> comes from would be a kernel internal decision, and could be
> implemented in a myriad of different ways for different architectures.

Yeah, something like that. For the non-EFI setups, the kernel boot
protocol could have an extension where the boot loader or the firmware
can pass generic key/value pairs to the starting kernel and the kernel
exports them; just like the volatile variables of EFI provide us.

> Also note that ACPI 5.0 exports this timing information in a generic
> way anyway. Given that ACPI is fairly standard and apparently is even
> what embedded is standardizing on I'd be open to adding native support
> for parsing this info from ACPI to systemd, if it's easy enough.

The ACPI "Firmware Basic Boot Performance Data Record" provides some
values on more recent firmware versions:
  $ sudo ./test-boot-timestamp
  ACPI FPDT: loader start=7.994s exit=8.115s duration=120ms
  EFI Loader: start=7.994s exit=8.080s duration=86ms
  Firmware began 8.115550s before kernel.
  Loader began 120.791ms before kernel.

The ACPI values are accessible after the system booted up, just like
EFI variables are.

For platforms which do not have anything like that, the kernel boot
protocol still sounds like the closest thing to fill the gap.

> However, beyond that: please abstract this in the kernel, I don#t want
> to see tons of drivers for this in systemd.

Yeah, we should not invent things here to cover for missing core features.

Kay