[Top][All Lists]

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

Re: [PATCH v22 06/17] meson: add target_user_arch

From: Philippe Mathieu-Daudé
Subject: Re: [PATCH v22 06/17] meson: add target_user_arch
Date: Wed, 24 Feb 2021 23:53:26 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0

On 2/24/21 11:35 PM, Eric Blake wrote:
> On 2/24/21 3:21 PM, Philippe Mathieu-Daudé wrote:
>> On 2/24/21 2:34 PM, Claudio Fontana wrote:
>>> the lack of target_user_arch makes it hard to fully leverage the
>>> build system in order to separate user code from sysemu code.
>>> Provide it, so that we can avoid the proliferation of #ifdef
>>> in target code.
>>> Signed-off-by: Claudio Fontana <cfontana@suse.de>
>>> Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
>>> [claudio: added changes for new target hexagon]
>> Again, this line goes ...
>>> ---
>> ... here. Else it is not stripped by git-am and ends
>> burried in the repository (see commit 940e43aa30e).
> If you are modifying a patch originally written by someone else (that
> is, their S-o-b appears first, but your edits mean you also add S-o-b),
> it is courteous to include your modifications in the commit log in this
> manner.  (For an example, see commit 2c4c556e06)
> You're right that it can look fishy if your changlog appears on your own
> commit (if you rebased things with no one else touching the patch in
> between, just update the commit message as part of that rebase; the
> changelog goes after the --- for review in that case).  But it's not
> completely wrong: you'll see me doing it when wearing my maintainer hat
> and preparing a pull request, and modifying my own patch different from
> how it was posted on the mailing list while wearing my developr hat
> prior to the pull request (see commit c930831446 for an example)

In that case that makes sense indeed (although in Claudio's case I
find it more confusing).



reply via email to

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