[Top][All Lists]

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

Re: [RFC v17 10/14] i386: split tcg btp_helper into softmmu and user par

From: Philippe Mathieu-Daudé
Subject: Re: [RFC v17 10/14] i386: split tcg btp_helper into softmmu and user parts
Date: Thu, 11 Feb 2021 11:39:03 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0

On 2/11/21 11:07 AM, Claudio Fontana wrote:
> On 2/10/21 5:28 PM, Alex Bennée wrote:
>> Claudio Fontana <cfontana@suse.de> writes:
>> s/btp/bpt/ in subject line...
>>> Signed-off-by: Claudio Fontana <cfontana@suse.de>
>>> ---
>>>  target/i386/tcg/helper-tcg.h                 |   3 +
>>>  target/i386/tcg/bpt_helper.c                 | 275 -----------------
>>>  target/i386/tcg/softmmu/bpt_helper_softmmu.c | 293 +++++++++++++++++++
>>>  target/i386/tcg/user/bpt_helper_user.c       |  33 +++
>> So I'm not sure about totally mirroring the file names in softmmu/user
>> subdirs. I can see it makes sense in some cases where there are genuine
>> functional differences between the two. However for everything that
>> exists only for one mode we might as well throw the stubs into one file.
>> Maybe target/tcg/user/stubs.c in this case?
> Hi Alex, I think you are right, repeating the _softmmu , _user seems too much.
> On similar things in the past Paolo mentioned that he favours simpler naming.
> In this case I could do for example:
> target/i386/tcg/seg_helper.c          - seg helper common parts
> target/i386/tcg/softmmu/seg_helper.c  - seg helper softmmu-only code
> target/i386/tcg/user/seg_helper.c     - seg helper user-only code

What about:

  target/i386/tcg/seg_helper.c          - seg helper common parts
  target/i386/tcg/seg_helper_softmmu.c  - seg helper softmmu-only code
  target/i386/tcg/seg_helper_user.c     - seg helper user-only code

> For the parts that are just stubs really (like here bpt for user), I would 
> like to see if I can remove them completely if possible..

It is probably worth spend time on this first. If the helpers are not
needed, why do we generate the code in the first place?

> Overall though, I am wondering whether this kind of change (extended more to 
> the rest of the target/ code) is an interesting approach,
> or does it make harder to work with the *_helper code, as people have to 
> chase down more files?
> Thank you!
> Claudio

reply via email to

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