Remained work,

the time and priority of work estimation.

We are open for discussion.

Thanks

PRIORITIES OF TESTS

0 highest, important for correct and effective work

1 verified functionality is not of high importance

2 mostly verified by other tests

3 verifying of not "standard" features

4 (bit fields of operation region) looks very important,

but hardware dependent and insufficiently specified for

to be verified; it is not clear from the specification

which actions and the relevant reactions we can operate

to verify this functionality; thus, it looks that only

low range of functionality can actually be there verified;

we can spend much time on trying to find out the grains

of hardware independent features capable for testing

but obtain the low effect in result.

To continue our efforts in this direction

we have to obtain clear information of the

features (expected actions & reactions) and

the information which of them are actually

supported by AcpiExec.

NO omit testing at all, impossible to verify

in our test suite

SUMMARY TIME ESTIMATION (in weeks for one person)

TIME(priority): <time/person>

1. TIME(2): 1 week/person

2. TIME(1): 1 hour/person

3. TIME(1): 1 day/person

4. TIME(3): 1 week/person

5. TIME(0): 1 week/person

6. TIME(0): 3 days/person

7. TIME(4): find difficulty in time estimation

8. TIME(NO): 0

9. TIME(0): 4 weeks/person (at least)

10. TIME(0): 4 weeks/person

11. TIME(0): 2 weeks/person

12. TIME(0): 3 weeks/person

13. TIME(0): 1 week/person

14. TIME(2): 1 week/person

15. TIME(3): 1 week/person

16. TIME(3): 1 week/person

17. TIME(3): 1 week/person

18. TIME(3): 2 days/person

Summary Time by priorities (in weeks for one person):

Priority 0: 16 weeks/person

Priority 1: 1 week/person

Priority 2: 2 weeks/person

Priority 3: 5 weeks/person

Priority 4: XXX

Time of test design/implementing depends on:

1) the considerable part of time is usually spent on

clarification of the actually expected behaviour of

the subject of testing.

2) fixing of current bugs is an actually essential point

in designing and implementing the tests. It allows more

deep and more quick implementation of the tests. Basing

on the current set of correct functionality we feel the

product by our tests more and more deeply. The current

bugs forces us to comment parts of tests, stop implementing

the new parts of tests based on the features which work

improperly.

DETAILS

* ====================================================== *

* A. Functional tests for particular ASL operators *

* ====================================================== *

1. TIME(2): 1 week/person

Do simplest separate test for each of these operators

which will be locations for further possible additions

(see e-mail RE:Planning ACPICA validation 19.11.2004,

304_simple_tests attachment for more details)

a) intensively applied in other tests and thus

might be considered being already verified

ArgX

LocalX

Name

Integer

String

Buffer

Store

CopyObject

b) will be verified comprehensively

in the new Name Space Complex test

Scope

Device

Processor

ThermalZone

PowerResource

2. TIME(1): 1 hour/person

Do simplest test, check only that execution

of this operator doesn't produce exception.

It is of low importance but doesn't require much time.

(see operators_have_no_separate_tests for more information)

NoOp

3. TIME(1): 1 day/person

Do the simple test, but not comprehensive

(see operators_have_no_separate_tests for more information)

Alias

4. TIME(3): 1 week/person

The test of "implicit return".

Implement the slack-mode test suite run,

and the test of "implicit return".

Add the relevant comment in README.

Return

5. TIME(0): 1 week/person

The functional test Return.

1. All different type declaration of Return.

2. Return different type objects.

3. Return references to different type objects.

4. Return Index references to elements of String,

Buffer and Package.

5. Return from different critical points of

the Method execution control operations:

If,ElseIf,Else,While,Switch,Case,Default.

Return

6. TIME(0): 3 days/person

Verify all assertions given in 17.5.49,

17.5.75 and 5.5.2 of ACPI specification.

Method

Function

7. TIME(4): find difficulty in time estimation

Bit fields complex test.

Very important, but looks hardware dependent

and insufficiently specified for to be verified.

Depends on particularities emulated by AcpiExec.

Looks that the tests will mostly verify emulation

(if any) of hardware which task is not important

as such, and it (emulation) may even be not provided

at all.

The ACPI specification is not sufficient to

understand which actions we can perform and

which reactions we should expect for those

actions.

It is not clear, which of these actions and reactions

are hardware dependent and, thus, could not be verified

in our test suite and which actions and reactions are

emulated and thus can be verified in our test suite.

Field

BankField

IndexField

OperationRegion

Offset

AccessAs

8. TIME(NO): 0

Omit testing at all, impossible to verify

in our test suite.

(see operators_have_no_separate_tests for more information)

Debug

Include

Fatal

Notify

Load

Unload

External

LoadTable

BreakPoint

DefinitionBlock

DataTableRegion

* ====================== *

* B. Complex tests *

* ====================== *

9. TIME(0): 4 weeks/person (at least)

The name space complex test.

Important.

Check the proper read and write access to the

objects in the namespace hierarchy generated by

the operators which open the new name scopes:

Scope

Device

Processor

ThermalZone

PowerResource

Method

Function

DefinitionBlock

These will be a group of sub-tests which will be

generating the different hierarchies of different

type objects (opening the new name scopes) and do

read and write operations in the critical points

passing them with the operands by all the possible

ways (mean absolute name, parent relative name,

current scope relative name, simple (search rules

apply) name, by reference, by alias, etc..) and

verify the obtained values.

From different nodes of the tree do access

(write/read) to different objects of other

nodes of the tree.

(see e-mail RE:Planning ACPICA validation 19.11.2004,

312_path_name attachment for more details)

10. TIME(0): 4 weeks/person

The declaration complex test.

Important and dont clear from ACPI specs.

The ACPICA allows an arbitrary place of different

declarations. Nevertheless, this causes some warnings,

crashes and other issues. This should be clarified and

verified.

(see e-mail RE:Planning ACPICA validation 19.11.2004,

311_test_names_accessibility attachment

for more details)

Addition feature: check that names declared by

Method are dead after the Method completion.

11. TIME(0): 2 weeks/person

Dynamic object deletion complex test.

Important for interpreter effective work.

To implement the "ACPICA extension",

a set of common ASL Methods to verify

the obtained memory consumption statistics

and the base set of the relevant ASL tests.

THE TESTS IN PROGRESS

12. TIME(0): 3 weeks/person

Complex test of references.

Verify all the aspects of access by

Object and Index references.

Remained to do:

a) Specify about 10 new sub-tests which now are

designated only. The total amount of sub-tests

will be then about 90.

b) Report the current bugs which are revealed

by the current state of test.

c) Wait for discussing and fixing current bugs.

After that implement the remained sub-tests.

Before that do something of scheduled.

Implemented for now are 60 sub-tests.

d) The reference beheviour is estimated on

ACPI compliance, legacy and sufficiency,

convenience and predictability.

e) Report remarks about the free and wide use of

"reference" word in ACPI specification which

produces the real mistakes and contradictions

of ACPI specification.

13. TIME(0): 1 week/person

Functional test of Match operator.

Functional test of Switch/Case/Default operators.

Update of these tests started after change of the

Match operator (bug 88) has not yet been completed.

THE TESTS REQUIRE UPDATE

The tests which don’t conform to the new

changed ACPI specification.

14. TIME(2): 1 week/person

Some tests were broken after the change of

functionality of Store operator (started with

e-mail "Behavior of Store() ASL operator").

Tests:

aslts/src/runtime/collections/complex/result/tests/rconversion

aslts/src/runtime/collections/complex/operand/tests/oconversion

REVIEW ACPICA AGAINST ASLTS

15. TIME(3): 1 week/person

Review the state of ACPICA against the

tests suite and prepare summary of bugs.

PREPARE THE SECOND RELEASE OF TEST SUITE

(see e-mail RE:Planning ACPICA validation 19.11.2004,

200_prepare_version and 201_cosmetic_update

attachments)

16. TIME(3): 1 week/person

Clean up code, remove the working comments.

Prepare files commented "in progress".

Comment the particular tests.

Do READMEs and HOW_TO_* files up to date and prepare some new.

17. TIME(3): 1 week/person

Prepare the test suite description.

NEW ADDITIONAL TESTS AND IMPROVEMENTS

18. TIME(3): 2 days/person

Describe all the thoughts of possible

improvement and new additional tests

and put it with the test suite.

-end