qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RFC v3 13/21] target-arm: Store JTAG_ID in ARMCP


From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH RFC v3 13/21] target-arm: Store JTAG_ID in ARMCPUClass
Date: Tue, 07 Feb 2012 23:07:50 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0

Am 07.02.2012 20:06, schrieb Peter Maydell:
> On 7 February 2012 18:41, Andreas Färber <address@hidden> wrote:
>> Am 07.02.2012 18:47, schrieb Peter Maydell:
>>> On 3 February 2012 02:59, Andreas Färber <address@hidden> wrote:
>>>> +    uint64_t jtag_id;
>>>
>>> If we're not using this anywhere we should just not have it.
>>
>> Andrzej will have had his reasons to put it in the code. This series
>> just moves code around so I don't want to remove it without his ack.
> 
> That was my point -- as far as I can see this patch *is* adding code
> and a struct field that wasn't there before.

Huh? Look closely, it *was* a comment in the original code. And I don't
want to *move* that comment over into my new code. Therefore I'm adding
a class field where such informational data can properly be stored and
inspected - per class, not per CPUState instance.

I can imagine storing much more information in a CPU class such as
vendor name*, description, logo, link to docs and chip color ;) to allow
for a nice lspci-like inspection.
* Yeah, in case of ARM the vendor can be inferred from CPUID so a getter
would be sufficient but you get the idea.

Again, I don't specifically need a jtag_id field, but this data is
definitely coming from existing code. If Andrzej doesn't respond here,
feel free to send a trivial patch to remove it from there.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



reply via email to

[Prev in Thread] Current Thread [Next in Thread]