Hi Guys,
I guess its time to put this to bed now that Roys patch has made it into acpica-tools and FWTS has been fixed to work without /dev/mem.
I produced the patch to expose these three tables from the kernel. BUT, is there actually a user for this? My gut feeling is no and they really contain little of interest anyway.
Does anyone actually have a use for the patch that makes it worth sending upstream?
Graeme
On 06/30/2015 03:25 AM, G Gregory wrote:
Hi Guys,
I guess its time to put this to bed now that Roys patch has made it into acpica-tools and FWTS has been fixed to work without /dev/mem.
I produced the patch to expose these three tables from the kernel. BUT, is there actually a user for this? My gut feeling is no and they really contain little of interest anyway.
Does anyone actually have a use for the patch that makes it worth sending upstream?
Graeme
Yes, for debugging purposes. The way acpidump works, afaict, is that I either get what's in /sys, or it reconstructs what the RSDP/RSDT/XSDT _should_ look like based on the tables currently being used. I'd rather be able to cat the actual data that was used at boot than have to assume that the acpidump reconstructed things properly. For example, I may have used the DSDT override in initrd which I believe would show up as a mismatch between the pointer to DSDT in XSDT and the pointer to DSDT in FADT. If acpidump is rebuilding an XSDT based on the DSDT it's using, I'm not sure I would be able to see that in the tables.