Re: The future of qemuarm

["Aníbal Limón" <anibal.limon@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 1927 bytes --]



On 10/17/2016 10:20 AM, Pascal Bach wrote:
> 
>>
>> Whatever we replace it with has to be part of linux-yocto and the meta data that is
>> carried there, so it can be used for the sanity/smoke test machine for arch arm.
>>
>> As such, it has to be feature compatible (network capabilities, disk boot, etc) with
>> the existing arm versatile 926ejs platform
>>
>> There have been newer variants for ages, but since there's been no compelling
>> reason to upgrade, I continue to carry the existing platform support along to the
>> new kernels. (In fact, I've had a qemuarma9 around for nearly 3 years now, but
>> it lacked some disk controller support).
> My main motivation is to get valgrind running. This requires at least armv7 to be useful.
> Most physical boards are not powerful enough (memory and cpu) to do real work with valgrind.
> QEMU would be helpful for that.
>>
>> From the kernel point of view, updating the platform doesn't have any big benefits,
>> but for userspace it could shake out issues with toolchains and instructions, so
>> there is a gain to be had there.
> In order to find more bugs there would be multiple qemuarms (qemuarm = armv5, qemuarmv7 = armv7, ...).
> Is this what you are suggesting?
>>
>> If someone is motivated, I'm happy to help work on an update to the core qemuarm
>> platform .. it just has to meet the criteria above.

I like the idea to have a new version of qemuarm instead of armv5 but
that needs to be considerate in terms of,

Do we aim to support multiple versions of qemuarm?, i'm saying this
because of the comments by Bruce about all the testing and the effort
needed to support another qemuarm variant.

If we only want one version of qemuarm, what version you suggest? and why?.

Finally i like the idea to be able to use valgrind into emulation that
will speed up debugging times.

Cheers,
	alimon

>>
> 
> Pascal
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]