http://bugzilla.kernel.org/show_bug.cgi?id=6389
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
------- Additional Comments From [EMAIL PROTECTED] 2006-04-29 10:34 -------
I have investigated the bug and prepared preliminary update
(it works, needs cosmetic) which provides strongly that when
the type of Name Space node (Node) (as well as pseudo nodes of
Args and Locals) is ACPI_TYPE_ANY, then the Node->Child is not
anyhow used in calculation. This new feature was meant to be used
then in update for bug (6389(212)) fixing. The field Node->Child was
considered to be used to keep temporary the address of the internal
object of the NS Node (Node->Object) in the interim between the object
of Node is detached and the following new object (if any) is attached
thus providing the RefOf references not to lose the objects they refer
to and handle not to delete NS Node until the last object it was referring
to (Node->Object stored to Node->Child) has non-zero NS-ReferenceCount
that is there are RefOf references pointing to that NS. If new object
is attached this Node->Child is processed and then Node->Child = NULL.
Started investigating and pre-implementing (started with Locals,
not tested or tried it yet for Args and not started implementing it
for NamedX) basing on the mentioned above new feature the reference
count for the Name Space Node to fix the root cause of the bug
(6389(212)). It would need additionally:
a) to allocate the ReferenceCount for NS Node though it could be
really located in its internal object (ACPI_OPERAND_OBJECT
structure),
b) to change arrays of pseudo nodes of ArgX and LocalX in
ACPI_WALK_STATE structure to the arrays of pointers to
the pseudo nodes of ArgX and LocalX which will be allocated
dynamically when actually needed.
Discussion needed.
Stopped working in front of dilemma -
do we actually want to implement the common mechanism of RefCounts
for the NS nodes to exclude undefined behaviour of bad AML program
(6389(212)) (has it other reasons?) or prefer to generate exception
when the attempt is made to generate suspicious RefOf reference which
potentially may have (but may not) bad consequences (for example, an
attempt is made to store RefOf-reference pointing to object O1 into
the object O2 which belongs to the higher than O1 level scope -
generate exception here). The exception in this case should be
then specified by ACPI.
Moreover, resolving (6389(212)) by adding RefCounts for NS would
mean the bad program would deal with the data of dead method.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
acpi-bugzilla mailing list
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
