On Mon, 2007-04-02 at 18:45 +0100, Paul Brook wrote: > A few issues with the patch, which I think need to be resolved before it can > be applied: > > - You're using global structures to store machine state. > While it's debatable whether you'll ever have more than one s3c2410, I think > it's definitely still worth allowing for this possibility, and encapsulating > the state in a structure, like all the other hardware emulation does.
Yes, I concur, this is my next goal. > - For the device emulation (dm9000 and ide, maybe others) you should use > pic_set_irq_new, instead of passing a separate set_irq function. Other ARM > boards already support arbitrary routing of interrupts via hw/arm_pic.[ch]. pic_set_irq_new appears to be missing from trunk unless I'm mistaken or confused. However hw/irq.[ch] seemed like a nice place to start, so I've made the s3c2410x_irq stuff use that, and ported all the other drivers we wrote to this. It has unfortunately added more global state for the s3c2410x which I will work on factoring into a new structure next. > - usb_ohci_mmap_init should look more like (or even be the same function as) > usb_ohci_init_pxa. I am now using usb_ohci_init_pxa for this. > What is the licence for ABLE? Would we be able to distribute it with qemu? ABLE is not going to be distributable *with* qemu, however it may be possible to ensure that the licence is such that anyone wishing to use ABLE with qemu will be allowed to in a free-beer sense by downloading it from Simtec's website. Would you mind casting your eye over the attached diff and tell me if I went the right way with the IRQ stuff? I'll get on with deglobalising (localising?) the s3c2410x state next. D. -- Daniel Silverstone http://www.simtec.co.uk/ PGP mail accepted and encouraged. Key Id: 2BC8 4016 2068 7895