Re: Allow acpidump(8) to disassemble SSDT AML data

[Bernd Ernesti <netbsd%lists.veego.de@localhost>]

On Tue, Sep 16, 2008 at 10:59:23AM +0200, Nicolas Joly wrote:
> On Tue, Sep 16, 2008 at 09:55:56AM +0200, Bernd Ernesti wrote:
> > On Tue, Sep 16, 2008 at 09:05:51AM +0200, Nicolas Joly wrote:
> > > 
> > > Hi,
> > > 
> > > On my DELL Optiplex 740, the ACPI tables include a SSDT which contains
> > > AML datas; but acpidump(8) does not support disassembling it, even if
> > > it can be handled just like the common DSDT table.
> > > 
> > > The attached patch, should fix it.
> > > 
> > > Does it looks ok ?
> > 
> > The version in basesrc is totally outdated and should either be updated
> > or dropped (in favour of the one in pkgsrc).
> 
> pksrc sysutils/acpidump is even worse that our one ... it doesn't work
> at all.

Maybe, I use my own intree version from a updated freebsd version.

Why is sysutils/acpidump there if it doesn't work and is the a pr about
this problem?

> > Where I would like to see to keep it, but that depends on some additional
> > acpica code which is not part of the source tree (the compiler part, but
> > I don't remeber the details when i updated it in my tree over an year ago).
> 
> If you're talking about sysutils/acpica-utils, i don't think all this
> stuff (compiler, ...) is needed in base. We only require a small tool
> to dump/disassemble ACPI tables for debugging purposes. Most users
> won't modify ACPI datas; otherwise, they will need more powerfull
> tools, which can be installed from pkgsrc.

The 'new' acpidump uses iasl and for that we need the compiler part.

Trying to fix an old acpidump instead of updating it is imho not a good idea,
but as I said this needs some other parts in the tree which is not there.

Bernd