I was just talking to some colleagues about PHAT recently as well.
The use case that jumps out is "system randomly rebooted while I was
doing XYZ". You don't know what happened, but you keep using your
system. Then it happens again.
If the reason for the random reboot is captured to dmesg you can cross
reference your journal from the next boot after any random reboot and
get the reason for it. If a user reports this to a Gitlab issue tracker
or Bugzilla it can be helpful in establishing a pattern.
The below location may be appropriate in that case:
/sys/firmware/acpi/
Yes, it may. >
We already have FPDT and BGRT being exported from there.
In fact, all of the ACPI tables can be retrieved verbatim from
/sys/firmware/acpi/tables/ already, so why exactly do you want the
kernel to parse PHAT in particular?
It's not to say that /sys/firmware/acpi/PHAT isn't useful, but having
something internal to the kernel "automatically" parsing it and saving
information to a place like the kernel log that is already captured by
existing userspace tools I think is "more" useful.
What existing user space tools do you mean? Is there anything already
making use of the kernel's PHAT output?
And why can't user space simply parse PHAT by itself?
> There are multiple ACPI tables that could be dumped into the kernel
log, but they aren't. Guess why.