[Devel] [PATCH] ACPICA: acpidump -- provide initial implementation for Linux
robert.moore at intel.com
Tue Jun 4 17:56:08 PDT 2013
> -----Original Message-----
> From: devel-bounces at acpica.org [mailto:devel-bounces at acpica.org] On Behalf
> Of Al Stone
> Sent: Sunday, June 02, 2013 1:04 PM
> To: devel at acpica.org
> Subject: Re: [Devel] [PATCH] ACPICA: acpidump -- provide initial
> implementation for Linux
> On 05/31/2013 10:22 PM, Al Stone wrote:
> > On 05/31/2013 06:46 PM, Moore, Robert wrote:
> >> Al,
> >> We've just completed and checked in a full implementation for Linux.
> >> You might want to inspect the code and see if there is anything that
> >> can be or should be merged. The code is at (or near) the head of our
> >> git tree.
> >> Thanks,
> >> Bob
> > Ah, interesting; I did a pull this afternoon and had not seen any such
> > changes. I'll take a look and see what can be merged.
> After looking at the two patches, there's not much that they share in
> common; I don't think there's anything that would make sense to merge --
> the approaches are very different.
> I do have a couple of concerns with the implementation,
> 1) While mmap() of /dev/mem makes sense, I suspect there
> are cases where one can attempt to mmap() the wrong
> address and lock up the system. I have not seen a good
> way to avoid this just yet without a priori being able
> to establish the proper physical addresses for the tables
> but that may require a kernel patch to provide the addresses
> via /sys. At a minimum, we should warn folks that this
> could happen. This was the only reason I did not include
> an implementation of AcpiOsGetTableByAddress().
> 2) I've seen at least a few systems with more than one UEFI
> table instance. Whether allowed or not, it looks like
> the acpidump code will only allow this for SSDTs.
If you find such a system, we would like to see the acpidump.
> Thanks for checking the code in. Now that I know an acpidump will be
> there, I can fix up the distro packages to handle this new version of the
> command properly, too.
> Al Stone
> Software Engineer
> Red Hat, Inc.
> ahs3 at redhat.com
> Devel mailing list
> Devel at acpica.org
More information about the Devel