From: Paolo Bonzini <pbonzini@redhat.com>
To: Peter Crosthwaite <peter.crosthwaite@petalogix.com>
Cc: edgar iglesias <edgar.iglesias@gmail.com>,
crwulff@gmail.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC v0 07/10] fdt_generic: First revision
Date: Mon, 17 Sep 2012 08:55:05 -0400 (EDT) [thread overview]
Message-ID: <2122228866.405132.1347886505085.JavaMail.root@redhat.com> (raw)
In-Reply-To: <CAEgOgz6phYwycCACsajmnJ=-ixGSvQjqzCf+eUiqmPmc5ao20g@mail.gmail.com>
> > 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.
Do you have any examples of things that are more complicated than
"build everything" followed by "resolve everything"?
> That and two pass is brutally ugly in code (and
> in-efficient) as you need to tag passes.
Not sure I follow, but I can't of course promise aesthetics without
having written any code.
> 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.
Ok, so something checks the syntax before initialization runs.
Pao
next prev parent reply other threads:[~2012-09-17 12:55 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-17 9:02 [Qemu-devel] [RFC v0 00/10] Microblaze generic FDT framework Peter A. G. Crosthwaite
2012-09-17 9:02 ` [Qemu-devel] [RFC v0 01/10] device_tree: allow offsets for cell properties Peter A. G. Crosthwaite
2012-09-17 9:02 ` [Qemu-devel] [RFC v0 02/10] device_tree: return Error* from prop getters Peter A. G. Crosthwaite
2012-09-17 9:02 ` [Qemu-devel] [RFC v0 03/10] device_tree: allow property getters to inherit Peter A. G. Crosthwaite
2012-09-17 9:02 ` [Qemu-devel] [RFC v0 04/10] device_tree: get_prop(): memdup returned properties Peter A. G. Crosthwaite
2012-09-17 9:02 ` [Qemu-devel] [RFC v0 05/10] qemu-coroutine: Add simple work queue support Peter A. G. Crosthwaite
2012-09-17 9:02 ` [Qemu-devel] [RFC v0 06/10] device_tree: Extended interface for fdt_generic Peter A. G. Crosthwaite
2012-09-17 9:02 ` [Qemu-devel] [RFC v0 07/10] fdt_generic: First revision Peter A. G. Crosthwaite
2012-09-17 9:48 ` Paolo Bonzini
2012-09-17 10:10 ` Peter Crosthwaite
2012-09-17 12:55 ` Paolo Bonzini [this message]
2012-09-17 9:03 ` [Qemu-devel] [RFC v0 08/10] pflash_cfi01: Added fdt generic platform support Peter A. G. Crosthwaite
2012-09-17 9:03 ` [Qemu-devel] [RFC v0 09/10] microblaze_generic_fdt: first revision Peter A. G. Crosthwaite
2012-09-17 15:20 ` Andreas Färber
2012-09-17 15:31 ` Paolo Bonzini
2012-09-17 9:03 ` [Qemu-devel] [RFC v0 10/10] serial: added fdt generic platform support Peter A. G. Crosthwaite
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2122228866.405132.1347886505085.JavaMail.root@redhat.com \
--to=pbonzini@redhat.com \
--cc=crwulff@gmail.com \
--cc=edgar.iglesias@gmail.com \
--cc=peter.crosthwaite@petalogix.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).