[Devel] [PATCH] ACPICA: acpidump -- provide initial implementation for Linux

Moore, Robert 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,
> though:
> 
> 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,
Bob





> 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.
> 
> --
> ciao,
> al
> -----------------------------------
> Al Stone
> Software Engineer
> Red Hat, Inc.
> ahs3 at redhat.com
> -----------------------------------
> _______________________________________________
> Devel mailing list
> Devel at acpica.org
> https://lists.acpica.org/mailman/listinfo/devel


More information about the Devel mailing list