Re: [Qemu-block] [Qemu-devel] [PATCH v3 01/46] Replace all occurances of __FUNCTION__ with __func__

[Alistair Francis]

On Wed, Nov 8, 2017 at 7:00 AM, Eric Blake  wrote:
> 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).

That's true, it didn't end up being that hard. I'm launching my tests
now, so I should be able to send the series out later today.

Hopefully some of this can make it in 2.11 :)

Thanks,
Alistair

>
> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.   +1-919-301-3266
> Virtualization:  qemu.org | libvirt.org
>

Re: [Qemu-block] [Qemu-devel] [PATCH v3 01/46] Replace all occurances of __FUNCTION__ with __func__

[Alistair Francis]

On Tue, Nov 7, 2017 at 11:52 PM, Markus Armbruster  wrote:
> Eric Blake  writes:
>
>> On 11/07/2017 04:12 AM, Markus Armbruster wrote:
>>> Juan Quintela  writes:
>>>
 Alistair Francis  wrote:
> Replace all occurs of __FUNCTION__ except for the check in checkpatch
> with the non GCC specific __func__.
>
>>
> +++ b/audio/audio_int.h
> @@ -253,7 +253,7 @@ static inline int audio_ring_dist (int dst, int src, 
> int len)
>  #define AUDIO_STRINGIFY(n) AUDIO_STRINGIFY_(n)
>
>  #if defined _MSC_VER || defined __GNUC__
> -#define AUDIO_FUNC __FUNCTION__
> +#define AUDIO_FUNC __func__
>  #else
>  #define AUDIO_FUNC __FILE__ ":" AUDIO_STRINGIFY (__LINE__)
>  #endif

 Unrelated to this patch 
 Do we really support other compilers than msc and gcc?
>>>
>>> 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.

Thanks,
Alistair

Re: [Qemu-block] [Qemu-devel] [PATCH v3 01/46] Replace all occurances of __FUNCTION__ with __func__

[Markus Armbruster]

Eric Blake  writes:

> On 11/07/2017 04:12 AM, Markus Armbruster wrote:
>> Juan Quintela  writes:
>> 
>>> Alistair Francis  wrote:
 Replace all occurs of __FUNCTION__ except for the check in checkpatch
 with the non GCC specific __func__.

>
 +++ b/audio/audio_int.h
 @@ -253,7 +253,7 @@ static inline int audio_ring_dist (int dst, int src, 
 int len)
  #define AUDIO_STRINGIFY(n) AUDIO_STRINGIFY_(n)
  
  #if defined _MSC_VER || defined __GNUC__
 -#define AUDIO_FUNC __FUNCTION__
 +#define AUDIO_FUNC __func__
  #else
  #define AUDIO_FUNC __FILE__ ":" AUDIO_STRINGIFY (__LINE__)
  #endif
>>>
>>> Unrelated to this patch 
>>> Do we really support other compilers than msc and gcc?
>> 
>> 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?

Re: [Qemu-block] [Qemu-devel] [PATCH v3 01/46] Replace all occurances of __FUNCTION__ with __func__

[Eric Blake]

On 11/07/2017 04:12 AM, Markus Armbruster wrote:
> Juan Quintela  writes:
> 
>> Alistair Francis  wrote:
>>> Replace all occurs of __FUNCTION__ except for the check in checkpatch
>>> with the non GCC specific __func__.
>>>

>>> +++ b/audio/audio_int.h
>>> @@ -253,7 +253,7 @@ static inline int audio_ring_dist (int dst, int src, 
>>> int len)
>>>  #define AUDIO_STRINGIFY(n) AUDIO_STRINGIFY_(n)
>>>  
>>>  #if defined _MSC_VER || defined __GNUC__
>>> -#define AUDIO_FUNC __FUNCTION__
>>> +#define AUDIO_FUNC __func__
>>>  #else
>>>  #define AUDIO_FUNC __FILE__ ":" AUDIO_STRINGIFY (__LINE__)
>>>  #endif
>>
>> Unrelated to this patch 
>> Do we really support other compilers than msc and gcc?
> 
> 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__).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-block] [Qemu-devel] [PATCH v3 01/46] Replace all occurances of __FUNCTION__ with __func__

[Markus Armbruster]

Juan Quintela  writes:

> Alistair Francis  wrote:
>> Replace all occurs of __FUNCTION__ except for the check in checkpatch
>> with the non GCC specific __func__.
>>
>> One line in hcd-musb.c was manually tweaked to pass checkpatch.
>>
>> Signed-off-by: Alistair Francis 
>> Cc: Gerd Hoffmann 
>> Cc: Andrzej Zaborowski 
>> Cc: Stefano Stabellini 
>> Cc: Anthony Perard 
>> Cc: John Snow 
>> Cc: Aurelien Jarno 
>> Cc: Yongbok Kim 
>> Cc: Peter Crosthwaite 
>> Cc: Stefan Hajnoczi 
>> Cc: Fam Zheng 
>> Cc: Juan Quintela 
>> Cc: "Dr. David Alan Gilbert" 
>> Cc: qemu-...@nongnu.org
>> Cc: qemu-block@nongnu.org
>> Cc: xen-de...@lists.xenproject.org
>> Reviewed-by: Eric Blake 
>> Reviewed-by: Stefan Hajnoczi 
>
> Reviewed-by: Juan Quintela 
>
>
>> diff --git a/audio/audio_int.h b/audio/audio_int.h
>> index 5bcb1c60e1..543b1bd8d5 100644
>> --- a/audio/audio_int.h
>> +++ b/audio/audio_int.h
>> @@ -253,7 +253,7 @@ static inline int audio_ring_dist (int dst, int src, int 
>> len)
>>  #define AUDIO_STRINGIFY(n) AUDIO_STRINGIFY_(n)
>>  
>>  #if defined _MSC_VER || defined __GNUC__
>> -#define AUDIO_FUNC __FUNCTION__
>> +#define AUDIO_FUNC __func__
>>  #else
>>  #define AUDIO_FUNC __FILE__ ":" AUDIO_STRINGIFY (__LINE__)
>>  #endif
>
> Unrelated to this patch 
> Do we really support other compilers than msc and gcc?

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__.