Re: bin/43121: acpidump(8) does not output all SSDT entries

[Jukka Ruohonen <jruohonen%iki.fi@localhost>]

The following reply was made to PR bin/43121; it has been noted by GNATS.

From: Jukka Ruohonen <jruohonen%iki.fi@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: bin/43121: acpidump(8) does not output all SSDT entries
Date: Fri, 11 Jun 2010 02:24:23 +0300

  
 After talking to Gregoire Sutre, we were able to understand what the problem
 is. It is not the External() but the Load() opcode, which loads additional
 tables dynamically. Again an example from the ThinkPad X60s:
 
        OperationRegion (IST0, SystemMemory,
                DerefOf (Index (SSDT, 0x01)), DerefOf (Index (SSDT, 0x02)))
 
        Load (IST0, HI0)
 
 where the required address is conveyed in the OperationRegion declaration.
 
 The kernel has no problems dealing with this, but increasingly it appears
 that acpidump(8) is broken beyond repair; parsing the address from the above
 operation region requires the help of the interpreter, and even then it can
 be dangeours, given that /dev/mem is involved.
 
 Note also that a similar acpidump program on Linux is broken as well.
 
 As said, dealing with this is easy in the kernel. A possible solution would
 be to pass the data from the kernel to the userland via an ioctl or an
 equivalent mechanism. This would likely be the end of acpidump(8) as we know
 it.
 
 I am working towards a solution, but it is unlikely to appear in the
 foreseeable future.