> > I don't think it is considered for inclusion. Before it is merged I
> > would like to separate the generic OMAP code from board-related code
> > (the board I emulate is the Palm Tunsgten|E handheld), but I imagine
> > the QEMU maintainers won't like the way code is formatted and probably
> > many other things, hard to say.
>
>   I really hoped to get response from QEMU author/ARM emulation maintainer
> regarding these points. Paul, any comments? Would you be interested to
> add more CPUs/boards? Any suggestion regarding this? Maybe if it is
> expected that there may be many implementation and they won't fit into
> core distribution, to provide API for plugin development?

I've no objection to adding new boards/cpus[1].

However, unless I have some personal/commercial interest in that particular 
board it's up to the patch author(s) to get that support into a state where 
I'm happy merging it. If the original author thinks it needs cleanup before 
submission I'm inclined to believe them ;-)

All the normal guidelines for patch submission apply. i.e. follow coding 
conventions, split changes into logically separate patches, don't mix 
cleanups with new features, etc.

Paul

[1] As discussed previously on this list there are unresolved legal issues 
with emulating ARMv6/v7 cpus, however that's not relevant in this case.


_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Reply via email to