Tagged all external interfaces to the subsystem with the
new ACPI_EXPORT_SYMBOL macro. This macro can be defined
as necessary to assist kernel integration. For Linux,
the macro resolves to the EXPORT_SYMBOL macro. The default
definition is NULL.
Added the ACPI_THREAD_ID type for the return value from
acpi_os_get_thread_id(). This allows the host to define this
as necessary to simplify kernel integration. The default
definition is ACPI_NATIVE_UINT.
Valery Podrezov fixed two interpreter problems related
to error processing, the deletion of objects, and placing
invalid pointers onto the internal operator result stack.
http://bugzilla.kernel.org/show_bug.cgi?id=6028http://bugzilla.kernel.org/show_bug.cgi?id=6151
Increased the reference count threshold where a warning is
emitted for large reference counts in order to eliminate
unnecessary warnings on systems with large namespaces
(especially 64-bit.) Increased the value from 0x400
to 0x800.
Due to universal disagreement as to the meaning of the
'c' in the calloc() function, the ACPI_MEM_CALLOCATE
macro has been renamed to ACPI_ALLOCATE_ZEROED so that the
purpose of the interface is 'clear'. ACPI_MEM_ALLOCATE and
ACPI_MEM_FREE are renamed to ACPI_ALLOCATE and ACPI_FREE.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Added 2006 copyright.
At SuSE's suggestion, enabled all error messages
without enabling function tracing, ie with CONFIG_ACPI_DEBUG=n
Replaced all instances of the ACPI_DEBUG_PRINT macro invoked at
the ACPI_DB_ERROR and ACPI_DB_WARN debug levels with
the ACPI_REPORT_ERROR and ACPI_REPORT_WARNING macros,
respectively. This preserves all error and warning messages
in the non-debug version of the ACPICA code (this has been
referred to as the "debug lite" option.) Over 200 cases
were converted to create a total of over 380 error/warning
messages across the ACPICA code. This increases the code
and data size of the default non-debug version by about 13K.
Added ACPI_NO_ERROR_MESSAGES flag to enable deleting all messages.
The size of the debug version remains about the same.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Fixed three cases in the interpreter where an "index"
argument to an ASL function was still (internally) 32
bits instead of the required 64 bits. This was the Index
argument to the Index, Mid, and Match operators.
The "strupr" function is now permanently local
(acpi_ut_strupr), since this is not a POSIX-defined
function and not present in most kernel-level C
libraries. References to the C library strupr function
have been removed from the headers.
Completed the deployment of static
functions/prototypes. All prototypes with the static
attribute have been moved from the headers to the owning
C file.
ACPICA 20050329 from Bob Moore
An error is now generated if an attempt is made to create
a Buffer Field of length zero (A CreateField with a length
operand of zero.)
The interpreter now issues a warning whenever executable
code at the module level is detected during ACPI table
load. This will give some idea of the prevalence of this
type of code.
Implemented support for references to named objects (other
than control methods) within package objects.
Enhanced package object output for the debug
object. Package objects are now completely dumped, showing
all elements.
Enhanced miscellaneous object output for the debug
object. Any object can now be written to the debug object
(for example, a device object can be written, and the type
of the object will be displayed.)
The "static" qualifier has been added to all local
functions across the core subsystem.
The number of "long" lines (> 80 chars) within the source
has been significantly reduced, by about 1/3.
Cleaned up all header files to ensure that all CA/iASL
functions are prototyped (even static functions) and the
formatting is consistent.
Two new header files have been added, acopcode.h and
acnames.h.
Removed several obsolete functions that were no longer
used.
Signed-off-by: Len Brown <len.brown@intel.com>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Bob Moore