Re: [PATCH] efi: expose TPM event log to userspace via sysfs

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Thu, 2024-04-25 at 11:58 +0200, Lennart Poettering wrote:
[...]
> General purpose distros typically don't build all TPM drivers into
> the kernel, but ship some in the initrd instead. Then, udev is
> responsible for iterating all buses/devices and auto-loading the
> necessary drivers. Each loaded bus driver might make more devices
> available for which more drivers then need to be loaded, and so on.
> Some of the busses are "slow" in the sense that we don't really know
> a precise time when we know that all devices have now shown up, there
> might always be slow devices that haven't popped up yet. Iterating
> through the entire tree of devices in sysfs is often quite slow in
> itself too, it's one of the most time consuming parts of the boot in
> fact. This all is done asynchronously hence: we
> enumerate/trigger/kmod all devices as quickly as we can, but we
> continue doing other stuff at the same time.

So let me make a suggestion that you can use now.  Since all you
currently care about is the EFI/ACPI device, there is always a single
sysfs entry that corresponds to that (so you shouldn't need the log
entry as an indicator):

/sys/bus/acpi/devices/MSFT0101\:00

That link (or a kobject uevent if you prefer to look for that) will
always appear regardless of whether a driver has attached or not.  When
the driver actually attaches, a driver/ directory will appear where the
link points.

The device link is added when the acpi scan is initiated as a
subsys_initcall, which is before all the filesystem initcalls, so it
should run before the initrd is mounted.

Is this enough for now and we can think about a more generic indicator
that all drivers have been probed later?

James