Re: [Qemu-devel] [RFC v0 07/10] fdt_generic: First revision

[Peter Crosthwaite]

On Mon, Sep 17, 2012 at 7:48 PM, Paolo Bonzini <address@hidden> wrote:
> Il 17/09/2012 11:02, Peter A. G. Crosthwaite ha scritto:
>> First revision of fdt generic infrastructure. These modules allow
>> for fdt generic machine models, which create machines to match a device
>> tree specification.
>
> Ok, so here is the famous coroutine-based FDT generation.  :)
>
> It does look pretty, to be fair.
>

Thanks :)

> However, as things stand there is nothing (I think) that really requires
> coroutines.  A simple 2-pass initialization would do, with links and
> irqs connected on the second pass.

I'm just trying to be a little more general. For more complex setups
we may in the future want to resolve dependencies at different phases
of the machine init process. The ability to yield arbitrarily solves
that problem universally rather than have to manage a discrete number
of passes. That and two pass is brutally ugly in code (and
in-efficient) as you need to tag passes.

I'm wondering how your patch fares
> in terms of error handling for example; can you end up with
> partially-uninitialized devices or infinite loops?  If so, why not?
>

Deadlock looping shouldnt happen if thats what your worried about.
Each device is instantiated before its able to yield (waiting on
another) and all devices are inited before you reach that
all-threads-are-yielded point. Essentially your "first-pass" as you
suggested above is complete before before every thread is yielded,
which makes deadlock impossible with current usages.

Paritally initied shouldnt happen - as that can only happen if
coroutines are left yielded. The machine init does not return until
all coros have exited.

Regards,
Peter

> It would be nice if you included some simple qtest test cases.  They
> would generate a few machines with different device trees and check that
> the output of "info qtree" matches somewhat the device tree.  Rough
> checks should not be hard to implement, and would provide some guidance
> to people who want to hack the code.
>
> Paolo