On 04/27/2018 01:53 AM, Markus Armbruster wrote:
> We could perhaps still declare *all* @arch values useless in v2.12.0,
> then fix them in v2.12.1.
>
Well, it's still useful to know that "s390" means the extra field is
available even in 2.12.0. But your plan:
> Or we deprecate @arch right whe
Laszlo Ersek writes:
> On 04/26/18 17:51, Markus Armbruster wrote:
>> Eric Blake writes:
>>
>>> On 04/26/2018 09:34 AM, Markus Armbruster wrote:
>
> Acerbic discovery of the day: @CpuInfoArch has "x86", while configure
> produces:
>
> TARGET_NAME TARGET_BASE_ARCH
>
On 04/26/18 17:51, Markus Armbruster wrote:
> Eric Blake writes:
>
>> On 04/26/2018 09:34 AM, Markus Armbruster wrote:
Acerbic discovery of the day: @CpuInfoArch has "x86", while configure
produces:
TARGET_NAME TARGET_BASE_ARCH
i386 i386
Eric Blake writes:
> On 04/26/2018 09:34 AM, Markus Armbruster wrote:
>>>
>>> Acerbic discovery of the day: @CpuInfoArch has "x86", while configure
>>> produces:
>>>
>>> TARGET_NAME TARGET_BASE_ARCH
>>> i386 i386
>>>x86_64 i386
>>>
>>> Note how "i386"
On 04/26/2018 09:34 AM, Markus Armbruster wrote:
>>
>> Acerbic discovery of the day: @CpuInfoArch has "x86", while configure
>> produces:
>>
>> TARGET_NAME TARGET_BASE_ARCH
>> i386 i386
>>x86_64 i386
>>
>> Note how "i386" does not match "x86".
>
> Revi
Laszlo Ersek writes:
> On 04/26/18 11:18, Laszlo Ersek wrote:
>> On 04/26/18 08:26, Markus Armbruster wrote:
>>> Laszlo Ersek writes:
>>>
>>> [...]
In brief, I think extending configure / the build system would only help
with the less painful part of this (the scalar mapping), and so i
On 04/26/18 11:18, Laszlo Ersek wrote:
> On 04/26/18 08:26, Markus Armbruster wrote:
>> Laszlo Ersek writes:
>>
>> [...]
>>> In brief, I think extending configure / the build system would only help
>>> with the less painful part of this (the scalar mapping), and so it's not
>>> worth doing.
>>
>>
Laszlo Ersek writes:
> On 04/26/18 08:26, Markus Armbruster wrote:
>> Laszlo Ersek writes:
>>
>> [...]
>>> In brief, I think extending configure / the build system would only help
>>> with the less painful part of this (the scalar mapping), and so it's not
>>> worth doing.
>>
>> We're going to
On 04/26/18 08:26, Markus Armbruster wrote:
> Laszlo Ersek writes:
>
> [...]
>> In brief, I think extending configure / the build system would only help
>> with the less painful part of this (the scalar mapping), and so it's not
>> worth doing.
>
> We're going to leave deprecated query-cpus alon
Laszlo Ersek writes:
[...]
> In brief, I think extending configure / the build system would only help
> with the less painful part of this (the scalar mapping), and so it's not
> worth doing.
We're going to leave deprecated query-cpus alone (see Eric's review of
the previous patch). Does that c
On 04/25/18 09:33, Markus Armbruster wrote:
> Laszlo Ersek writes:
[snip]
>> +static CpuInfoArch sysemu_target_to_cpuinfo_arch(SysEmuTarget target)
>> +{
>> +/*
>> + * The @SysEmuTarget -> @CpuInfoArch mapping below is based on the
>> + * TARGET_ARCH -> TARGET_BASE_ARCH mapping in th
Laszlo Ersek writes:
> Add a new field @target (of type @SysEmuTarget) to the outputs of the
> @query-cpus and @query-cpus-fast commands, which provides more information
> about the emulation target than the field @arch (of type @CpuInfoArch).
> Keep @arch for compatibility.
>
> Make @target the
Add a new field @target (of type @SysEmuTarget) to the outputs of the
@query-cpus and @query-cpus-fast commands, which provides more information
about the emulation target than the field @arch (of type @CpuInfoArch).
Keep @arch for compatibility.
Make @target the new discriminator for the @CpuInfo
13 matches
Mail list logo
