Am 19.10.2015 um 17:47 schrieb Eduardo Habkost: > On Sun, Oct 18, 2015 at 06:22:40PM +0200, Andreas Färber wrote: >> Am 18.10.2015 um 14:20 schrieb Michael S. Tsirkin: >>> On Sun, Oct 18, 2015 at 02:18:31PM +0300, Marcel Apfelbaum wrote: >>>> On 10/15/2015 06:12 AM, Zhu Guihua wrote: > [...] >>>>> - cpu = pc_new_cpu(current_cpu_model, apic_id, &local_err); >>>>> + cpu = pc_new_cpu(machine->cpu_model, apic_id, &local_err);t >>>> >>>> Hi, >>>> >>>> I am not going to "stop" this patch and I do agree with what is trying to >>>> do. >>>> What I still don't get is if we are "allowed" to directly access QOM >>>> object's private >>>> fields outside the implementation C file. >>>> >>>> This is why we have some wrappers in include/hw/boards.h when we access >>>> machine's fields. >>>> >>>> Just wanted to raise the question, other than that (for what is worth): >>>> Reviewed-by: Marcel Apfelbaum <mar...@redhat.com> >>> >>> Andreas, could you ack/nack this patch pls? >> >> I won't nack it, as putting it into the QOM state now is a good idea. >> But I would rather put this into PCMachineState, as current_cpu_model >> was PC-only and I'd prefer not to encourage more uses of the old API. > > I don't undersand what you suggest. The patch doesn't add any new state, > it is just updating the existing MachineState::cpu_model field (just > like it is already done by multiple arm, mips, ppc, and tricore > machines).
Looking at the full patch now, you are right. It is not adding a new field but merely setting it. Acked-by: Andreas Färber <afaer...@suse.de> Sorry for the confusion, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)
