[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
Re: [RFC v17 10/14] i386: split tcg btp_helper into softmmu and user parts
Thu, 11 Feb 2021 12:48:30 +0100
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
On 2/11/21 11:39 AM, Philippe Mathieu-Daudé wrote:
> On 2/11/21 11:07 AM, Claudio Fontana wrote:
>> On 2/10/21 5:28 PM, Alex Bennée wrote:
>>> Claudio Fontana <firstname.lastname@example.org> writes:
>>> s/btp/bpt/ in subject line...
>>>> Signed-off-by: Claudio Fontana <email@example.com>
>>>> 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
>> 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
I tried this one in particular, it looked a bit confusing and cluttered to me
when looking at the overall result:
>> 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?
Worth a good look.
>> 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!
[RFC v17 13/14] i386: slit svm_helper into softmmu and stub-only user, Claudio Fontana, 2021/02/10
[RFC v17 14/14] i386: split seg_helper into user-only and softmmu parts, Claudio Fontana, 2021/02/10
Re: [RFC v17 00/14] i386 cleanup PART 2, no-reply, 2021/02/11
- [RFC v17 01/14] i386: split cpu accelerators from cpu.c, using AccelCPUClass, (continued)
- [RFC v17 01/14] i386: split cpu accelerators from cpu.c, using AccelCPUClass, Claudio Fontana, 2021/02/10
- [RFC v17 05/14] accel-cpu: make cpu_realizefn return a bool, Claudio Fontana, 2021/02/10
- [RFC v17 07/14] i386: split user and softmmu functionality in tcg-cpu, Claudio Fontana, 2021/02/10
- [RFC v17 09/14] i386: split tcg excp_helper into softmmu and user parts, Claudio Fontana, 2021/02/10
- [RFC v17 12/14] i386: separate fpu_helper into user and softmmu parts, Claudio Fontana, 2021/02/10
- [RFC v17 11/14] i386: split misc helper into user and softmmu parts, Claudio Fontana, 2021/02/10
- [RFC v17 10/14] i386: split tcg btp_helper into softmmu and user parts, Claudio Fontana, 2021/02/10