qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v12 16/23] cpu: Move synchronize_from_tb() to tcg_ops


From: Claudio Fontana
Subject: Re: [PATCH v12 16/23] cpu: Move synchronize_from_tb() to tcg_ops
Date: Wed, 16 Dec 2020 09:44:14 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0

On 12/14/20 10:56 PM, Philippe Mathieu-Daudé wrote:
> Hi Claudio, Eduardo.
> 
> On 12/14/20 8:10 PM, Eduardo Habkost wrote:
>> On Sat, Dec 12, 2020 at 04:55:23PM +0100, Claudio Fontana wrote:
>>> From: Eduardo Habkost <ehabkost@redhat.com>
>>>
>>> since tcg_cpu_ops.h is only included in cpu.h,
>>> and as a standalone header it is not really useful,
>>> as tcg_cpu_ops.h starts requiring cpu.h defines,
>>> enums, etc, as well as (later on in the series),
>>> additional definitions coming from memattr.h.
>>>
>>> Therefore rename it to tcg_cpu_ops.h.inc, to warn
>>> any potential user that this file is not a standalone
>>> header, but rather a partition of cpu.h that is
>>> included conditionally if CONFIG_TCG is true.
>>
>> What's the benefit of moving definitions to a separate file, if
>> the new file is not a standalone header?
> 

the benefit is avoiding a 100 line ifdef CONFIG_TCG, and already separating out 
what is tcg-specific and what isn't,
but if this is a problem we can avoid that, and revisit later on.


> Claudio, I haven't been following every respin. If you did that
> change just to please me then the circular dependency remarked by
> Richard, then if it simplify the series I'm OK if you have to
> remove the includes.

Richard, From the answer of Philippe and Eduardo I think they are not ok with 
.h.inc,
I think the option of just putting everything in cpu.h was ok with you,
should I go with that?

Thanks,

Claudio


> 
> Eduardo, if you are happy with patches 1-8 (x86 specific), maybe
> you can queue them already. The rest is more TCG generic and
> will likely go via Richard/Paolo trees IMO.
> 
>>
>> If moving the definitions to a separate header is going to
>> require too much work, it's completely OK to keep them in cpu.h
>> by now, and try to move them later.
>>
>> I'm worried that the scope of this series is growing too much,
>> and discussion/review of additional changes in each new version
>> is preventing us from merging the original changes where we
>> already had some consensus.
> 




reply via email to

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