tree f3630ab9fb02c439f1b55b12497ae863b7063cef
parent b274ef5eedd5b577b2ef63999e338a327975febd
author mbligh <mbligh@592f7852-d20e-0410-864c-8624ca9c26a4> 1212435770 +0000
committer mbligh <mbligh@592f7852-d20e-0410-864c-8624ca9c26a4> 1212435770 +0000

Creates job.next_step_append whose behavior matches that of the current
job.next_step and then change the semantics of job.next_step so that
the step engine's behavior is more like a depth first search than a
breadth first search.

I believe that it's more intuitive to users to have the steps most
recently added be run first, but be run in the order they were added
within the function.  Here's an example of what I mean:

def step_init():
        job.next_step('a')
        job.next_step('b')
def a():
        print "a"
        job.next_step('a1')
def a1():
        print "a1"
def b():
        print "b"

With the old behavior, you'd see "a b a1"
With the new behavior, you'd see "a a1 b"

You'll notice that the old behavior is like a BFS in that it processes
things exactly in the order that they're added (i.e. a queue).  The
new behavior processes things as a stack.  This could be acomplished
via job.next_step_prepend except for the fact that you have to add
steps in the reverse order you intend for them to run.  For example,
to get 1, 2, 3, you'd write the following code:

def step_init():
job.next_step_prepend('c')
job.next_step_prepend('b')
job.next_step_prepend('a')
def a():
print "1"
def b():
print "2"
def c():
print "3"

With the new code, job.next_step will place it after all steps added
in this step already but before any steps added in other steps.


Signed-off-by: Jeremy Orlow <jorlow@google.com>


git-svn-id: http://test.kernel.org/svn/autotest/trunk@1583 592f7852-d20e-0410-864c-8624ca9c26a4