On Tuesday, May 13, 2014, Andreas Färber <[email protected]> wrote: > Am 12.05.2014 13:09, schrieb Peter Maydell: > > On 12 May 2014 11:30, Peter Crosthwaite > > <[email protected]<javascript:;>> > wrote: > >> On Mon, May 12, 2014 at 7:44 PM, Peter Maydell < > [email protected] <javascript:;>> wrote: > >>> On 12 May 2014 10:10, Juan Quintela <[email protected]<javascript:;>> > wrote: > >>>> Please, send any topic that you are interested in covering. > >>>> > >>>> - QOMifying both Memory regions and GPIOs and attaching them via QOM > >>>> links (Peter Crosthwaite) > >>> > >>> Is there some further useful material on-list on this subject, or > >>> are we just going to have a rerun of the discussions on the > >>> last two calls? > > > >> I have any ugly work-in-progress series. TBH I was going to wait for > >> discussion outcomes. Want me to RFC it? > > > > I don't think you necessarily need to post code, but maybe a writeup > > of current status/options would be useful to try to make the on-call > > discussion productive? > > Here's my WIP qemu_irq conversion, so that we don't discuss IRQs for the > third time in a row without results: > > https://github.com/afaerber/qemu-cpu/commits/qom-irq
Same basic idea as my wip series. No conflict of design at all. I've done some stuff around parenting irqs to their devs that would build onto this. regards, Peter > > make check passes, not further tested yet. > As a side effect, cleaning up the leaks turned out rather easy. > > The only remaining users of qemu_free_irqs() are serial-pci.c and > ipack.c. If we can get rid of it altogether, the hacks for freeing the > memory chunk could be avoided. > > Regards, > Andreas > > -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg > >
