On 11/08/2017 08:51 AM, Alistair Francis wrote: >>>> Let me rephrase the question: do we really support compilers that don't >>>> understand __func__? The presence of numerous unconditional uses of >>>> __func__ in the tree means the answer is no. Let's replace AUDIO_FUNC >>>> by plain __func__. >>> >>> Answered elsewhere in patch 3/46 (where we DO replace AUDIO_FUNC by >>> __func__). >> >> I see. >> >> Put 03/46 first, so we don't have to mess with AUDIO_FUNC twice? > > I would really like to avoid that, as the conflicts will be a bit of a > mess. The way I see it there will be a lot of churn no matter what, > so we don't gain much by swapping the order around. > > I have a new series ready to send today, so I'm going to send that > through as I would like at least some of these patches to make it in > 2.11. After that if you think strongly the order should be changed I > can change it in the next version.
I think the reorder is not that hard. Put 3/46 first (changing AUDIO_FUNC to __func__), and then 1/46 doesn't have to touch any of the files that used to use AUDIO_FUNC, because there is no intermediate state using __FUNCTION__. If I'm reading it correctly, the rebase conflict is limited to a slight rewording of the commit message for 3/46, and one line in 1/46 to the definition of AUDIO_FUNC (that will no longer be present). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel