From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46801) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RutEw-0000pL-Iw for qemu-devel@nongnu.org; Tue, 07 Feb 2012 17:10:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RutEt-000140-Js for qemu-devel@nongnu.org; Tue, 07 Feb 2012 17:10:18 -0500 Received: from cantor2.suse.de ([195.135.220.15]:42596 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RutEt-00013s-92 for qemu-devel@nongnu.org; Tue, 07 Feb 2012 17:10:15 -0500 Message-ID: <4F31A0B6.8040408@suse.de> Date: Tue, 07 Feb 2012 23:07:50 +0100 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1328237992-14953-1-git-send-email-afaerber@suse.de> <1328237992-14953-14-git-send-email-afaerber@suse.de> <4F317056.5030804@suse.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH RFC v3 13/21] target-arm: Store JTAG_ID in ARMCPUClass List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: qemu-devel@nongnu.org Am 07.02.2012 20:06, schrieb Peter Maydell: > On 7 February 2012 18:41, Andreas F=C3=A4rber wrote: >> Am 07.02.2012 18:47, schrieb Peter Maydell: >>> On 3 February 2012 02:59, Andreas F=C3=A4rber wrot= e: >>>> + 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. >=20 > 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 --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg