On 2/04/2014 4:15 am, Joel Sherrill wrote:
Hi
Should there be separate qemu configurations for each target architecture?
I know from my experience in the past that it is rare for all of them to be
working at the same time and patches apply cleanly.
qemu can be built for a single target so I thought this makes sense.
Yeah good point and it does make sense from our point of view. The only
problem is it stopping us being able to check what qemu is up to and
what has regressed. If we can figure out a way to manage this maybe it
would help.
At this point, we have separate arm and sparc patches floating around
and I was going to go back through my qemu versions and try to get
them into rsb. Some use patches against old versions. Yes.. they need to
be updated, but they are all out of sync now, just like gcc and friends
can be.
Thoughts?
I would need to see each patch. It does kind of support the reason for
keeping as close to the current code as we can. We need working qemu
versions but it is not quite as critical as a compiler and we need to be
testing on real hardware as validate the qemu based results.
The RSB support patchworks and this has let me follow qemu at that
level. It seems with qemu git+patchworks is as close to mainline as I
can see we can get to. I really cannot not follow the process in qemu
and how patches are moved from patchworks to the git repo.
Chris
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
