All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] btrfs-progs: fix 64-bit mips and powerpc types
@ 2022-01-30  1:09 Rosen Penev
  2022-01-31 14:39 ` David Sterba
  0 siblings, 1 reply; 10+ messages in thread
From: Rosen Penev @ 2022-01-30  1:09 UTC (permalink / raw)
  To: linux-btrfs

The kernel uses unsigned long specifically for ppc64 and mips64. This
fixes that.

Removed asm/types.h include as it will get included properly later.

Fixes -Wformat warnings.

Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
 cmds/receive-dump.c | 1 -
 kerncompat.h        | 4 ++++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/cmds/receive-dump.c b/cmds/receive-dump.c
index 47a0a30e..00ad4fd1 100644
--- a/cmds/receive-dump.c
+++ b/cmds/receive-dump.c
@@ -31,7 +31,6 @@
 #include <stdlib.h>
 #include <time.h>
 #include <ctype.h>
-#include <asm/types.h>
 #include <uuid/uuid.h>
 #include "common/utils.h"
 #include "cmds/commands.h"
diff --git a/kerncompat.h b/kerncompat.h
index 6ca1526e..4b36b45a 100644
--- a/kerncompat.h
+++ b/kerncompat.h
@@ -19,6 +19,10 @@
 #ifndef __KERNCOMPAT_H__
 #define __KERNCOMPAT_H__
 
+#ifndef __SANE_USERSPACE_TYPES__
+#define __SANE_USERSPACE_TYPES__	/* For PPC64, to get LL64 types */
+#endif
+
 #include <stdio.h>
 #include <stdlib.h>
 #include <errno.h>
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [PATCH] btrfs-progs: fix 64-bit mips and powerpc types
  2022-01-30  1:09 [PATCH] btrfs-progs: fix 64-bit mips and powerpc types Rosen Penev
@ 2022-01-31 14:39 ` David Sterba
  2022-01-31 20:46   ` Rosen Penev
  0 siblings, 1 reply; 10+ messages in thread
From: David Sterba @ 2022-01-31 14:39 UTC (permalink / raw)
  To: Rosen Penev; +Cc: linux-btrfs

On Sat, Jan 29, 2022 at 05:09:56PM -0800, Rosen Penev wrote:
> The kernel uses unsigned long specifically for ppc64 and mips64. This
> fixes that.

What do you mean? Uses unsigned long for what?

> Removed asm/types.h include as it will get included properly later.
> 
> Fixes -Wformat warnings.
> 
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
>  cmds/receive-dump.c | 1 -
>  kerncompat.h        | 4 ++++
>  2 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/cmds/receive-dump.c b/cmds/receive-dump.c
> index 47a0a30e..00ad4fd1 100644
> --- a/cmds/receive-dump.c
> +++ b/cmds/receive-dump.c
> @@ -31,7 +31,6 @@
>  #include <stdlib.h>
>  #include <time.h>
>  #include <ctype.h>
> -#include <asm/types.h>
>  #include <uuid/uuid.h>
>  #include "common/utils.h"
>  #include "cmds/commands.h"
> diff --git a/kerncompat.h b/kerncompat.h
> index 6ca1526e..4b36b45a 100644
> --- a/kerncompat.h
> +++ b/kerncompat.h
> @@ -19,6 +19,10 @@
>  #ifndef __KERNCOMPAT_H__
>  #define __KERNCOMPAT_H__
>  
> +#ifndef __SANE_USERSPACE_TYPES__
> +#define __SANE_USERSPACE_TYPES__	/* For PPC64, to get LL64 types */
> +#endif

Is there a cleaner way instead of defining magic macros?

> +
>  #include <stdio.h>
>  #include <stdlib.h>
>  #include <errno.h>
> -- 
> 2.34.1

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] btrfs-progs: fix 64-bit mips and powerpc types
  2022-01-31 14:39 ` David Sterba
@ 2022-01-31 20:46   ` Rosen Penev
  2022-02-01 12:58     ` Qu Wenruo
  0 siblings, 1 reply; 10+ messages in thread
From: Rosen Penev @ 2022-01-31 20:46 UTC (permalink / raw)
  To: dsterba, Rosen Penev, linux-btrfs

On Mon, Jan 31, 2022 at 6:40 AM David Sterba <dsterba@suse.cz> wrote:
>
> On Sat, Jan 29, 2022 at 05:09:56PM -0800, Rosen Penev wrote:
> > The kernel uses unsigned long specifically for ppc64 and mips64. This
> > fixes that.
>
> What do you mean? Uses unsigned long for what?
kernel's u64 is normally unsigned long long, but not for ppc64 and mips64.
>
> > Removed asm/types.h include as it will get included properly later.
> >
> > Fixes -Wformat warnings.
> >
> > Signed-off-by: Rosen Penev <rosenp@gmail.com>
> > ---
> >  cmds/receive-dump.c | 1 -
> >  kerncompat.h        | 4 ++++
> >  2 files changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/cmds/receive-dump.c b/cmds/receive-dump.c
> > index 47a0a30e..00ad4fd1 100644
> > --- a/cmds/receive-dump.c
> > +++ b/cmds/receive-dump.c
> > @@ -31,7 +31,6 @@
> >  #include <stdlib.h>
> >  #include <time.h>
> >  #include <ctype.h>
> > -#include <asm/types.h>
> >  #include <uuid/uuid.h>
> >  #include "common/utils.h"
> >  #include "cmds/commands.h"
> > diff --git a/kerncompat.h b/kerncompat.h
> > index 6ca1526e..4b36b45a 100644
> > --- a/kerncompat.h
> > +++ b/kerncompat.h
> > @@ -19,6 +19,10 @@
> >  #ifndef __KERNCOMPAT_H__
> >  #define __KERNCOMPAT_H__
> >
> > +#ifndef __SANE_USERSPACE_TYPES__
> > +#define __SANE_USERSPACE_TYPES__     /* For PPC64, to get LL64 types */
> > +#endif
>
> Is there a cleaner way instead of defining magic macros?
no. https://github.com/torvalds/linux/blob/master/arch/powerpc/include/uapi/asm/types.h#L18
>
> > +
> >  #include <stdio.h>
> >  #include <stdlib.h>
> >  #include <errno.h>
> > --
> > 2.34.1

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] btrfs-progs: fix 64-bit mips and powerpc types
  2022-01-31 20:46   ` Rosen Penev
@ 2022-02-01 12:58     ` Qu Wenruo
  2022-02-01 13:44       ` David Sterba
  0 siblings, 1 reply; 10+ messages in thread
From: Qu Wenruo @ 2022-02-01 12:58 UTC (permalink / raw)
  To: Rosen Penev, linux-btrfs



On 2022/2/1 04:46, Rosen Penev wrote:
> On Mon, Jan 31, 2022 at 6:40 AM David Sterba <dsterba@suse.cz> wrote:
>>
>> On Sat, Jan 29, 2022 at 05:09:56PM -0800, Rosen Penev wrote:
>>> The kernel uses unsigned long specifically for ppc64 and mips64. This
>>> fixes that.
>>
>> What do you mean? Uses unsigned long for what?
> kernel's u64 is normally unsigned long long, but not for ppc64 and mips64.
>>
>>> Removed asm/types.h include as it will get included properly later.
>>>
>>> Fixes -Wformat warnings.
>>>
>>> Signed-off-by: Rosen Penev <rosenp@gmail.com>
>>> ---
>>>   cmds/receive-dump.c | 1 -
>>>   kerncompat.h        | 4 ++++
>>>   2 files changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/cmds/receive-dump.c b/cmds/receive-dump.c
>>> index 47a0a30e..00ad4fd1 100644
>>> --- a/cmds/receive-dump.c
>>> +++ b/cmds/receive-dump.c
>>> @@ -31,7 +31,6 @@
>>>   #include <stdlib.h>
>>>   #include <time.h>
>>>   #include <ctype.h>
>>> -#include <asm/types.h>
>>>   #include <uuid/uuid.h>
>>>   #include "common/utils.h"
>>>   #include "cmds/commands.h"
>>> diff --git a/kerncompat.h b/kerncompat.h
>>> index 6ca1526e..4b36b45a 100644
>>> --- a/kerncompat.h
>>> +++ b/kerncompat.h
>>> @@ -19,6 +19,10 @@
>>>   #ifndef __KERNCOMPAT_H__
>>>   #define __KERNCOMPAT_H__
>>>
>>> +#ifndef __SANE_USERSPACE_TYPES__
>>> +#define __SANE_USERSPACE_TYPES__     /* For PPC64, to get LL64 types */
>>> +#endif
>>
>> Is there a cleaner way instead of defining magic macros?
> no. https://github.com/torvalds/linux/blob/master/arch/powerpc/include/uapi/asm/types.h#L18

Really?

I have the same issue in btrfs-fuse, but it can be easily solved without
using the magic macro.

See this issue:

https://github.com/adam900710/btrfs-fuse/issues/2

including <linux/types.h> seems to solve it for btrfs-fuse.

Thanks,
Qu

>>
>>> +
>>>   #include <stdio.h>
>>>   #include <stdlib.h>
>>>   #include <errno.h>
>>> --
>>> 2.34.1

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] btrfs-progs: fix 64-bit mips and powerpc types
  2022-02-01 12:58     ` Qu Wenruo
@ 2022-02-01 13:44       ` David Sterba
  2022-02-02  0:11         ` Rosen Penev
  0 siblings, 1 reply; 10+ messages in thread
From: David Sterba @ 2022-02-01 13:44 UTC (permalink / raw)
  To: Qu Wenruo; +Cc: Rosen Penev, linux-btrfs

On Tue, Feb 01, 2022 at 08:58:55PM +0800, Qu Wenruo wrote:
> 
> 
> On 2022/2/1 04:46, Rosen Penev wrote:
> > On Mon, Jan 31, 2022 at 6:40 AM David Sterba <dsterba@suse.cz> wrote:
> >>
> >> On Sat, Jan 29, 2022 at 05:09:56PM -0800, Rosen Penev wrote:
> >>> The kernel uses unsigned long specifically for ppc64 and mips64. This
> >>> fixes that.
> >>
> >> What do you mean? Uses unsigned long for what?
> > kernel's u64 is normally unsigned long long, but not for ppc64 and mips64.
> >>
> >>> Removed asm/types.h include as it will get included properly later.
> >>>
> >>> Fixes -Wformat warnings.
> >>>
> >>> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> >>> ---
> >>>   cmds/receive-dump.c | 1 -
> >>>   kerncompat.h        | 4 ++++
> >>>   2 files changed, 4 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/cmds/receive-dump.c b/cmds/receive-dump.c
> >>> index 47a0a30e..00ad4fd1 100644
> >>> --- a/cmds/receive-dump.c
> >>> +++ b/cmds/receive-dump.c
> >>> @@ -31,7 +31,6 @@
> >>>   #include <stdlib.h>
> >>>   #include <time.h>
> >>>   #include <ctype.h>
> >>> -#include <asm/types.h>
> >>>   #include <uuid/uuid.h>
> >>>   #include "common/utils.h"
> >>>   #include "cmds/commands.h"
> >>> diff --git a/kerncompat.h b/kerncompat.h
> >>> index 6ca1526e..4b36b45a 100644
> >>> --- a/kerncompat.h
> >>> +++ b/kerncompat.h
> >>> @@ -19,6 +19,10 @@
> >>>   #ifndef __KERNCOMPAT_H__
> >>>   #define __KERNCOMPAT_H__
> >>>
> >>> +#ifndef __SANE_USERSPACE_TYPES__
> >>> +#define __SANE_USERSPACE_TYPES__     /* For PPC64, to get LL64 types */
> >>> +#endif
> >>
> >> Is there a cleaner way instead of defining magic macros?
> > no. https://github.com/torvalds/linux/blob/master/arch/powerpc/include/uapi/asm/types.h#L18
> 
> Really?
> 
> I have the same issue in btrfs-fuse, but it can be easily solved without
> using the magic macro.
> 
> See this issue:
> 
> https://github.com/adam900710/btrfs-fuse/issues/2
> 
> including <linux/types.h> seems to solve it for btrfs-fuse.

Ok, so it's just the asm/types.h, once it's deleted it should all work
with linux/types.h (included via kerncompat.h).

Rosen, could you please verify that this is sufficient (without the
extra macro)?

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] btrfs-progs: fix 64-bit mips and powerpc types
  2022-02-01 13:44       ` David Sterba
@ 2022-02-02  0:11         ` Rosen Penev
  2022-02-02  0:31           ` Qu Wenruo
  2022-02-04 18:40           ` David Sterba
  0 siblings, 2 replies; 10+ messages in thread
From: Rosen Penev @ 2022-02-02  0:11 UTC (permalink / raw)
  To: dsterba, Qu Wenruo, Rosen Penev, linux-btrfs

On Tue, Feb 1, 2022 at 5:44 AM David Sterba <dsterba@suse.cz> wrote:
>
> On Tue, Feb 01, 2022 at 08:58:55PM +0800, Qu Wenruo wrote:
> >
> >
> > On 2022/2/1 04:46, Rosen Penev wrote:
> > > On Mon, Jan 31, 2022 at 6:40 AM David Sterba <dsterba@suse.cz> wrote:
> > >>
> > >> On Sat, Jan 29, 2022 at 05:09:56PM -0800, Rosen Penev wrote:
> > >>> The kernel uses unsigned long specifically for ppc64 and mips64. This
> > >>> fixes that.
> > >>
> > >> What do you mean? Uses unsigned long for what?
> > > kernel's u64 is normally unsigned long long, but not for ppc64 and mips64.
> > >>
> > >>> Removed asm/types.h include as it will get included properly later.
> > >>>
> > >>> Fixes -Wformat warnings.
> > >>>
> > >>> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> > >>> ---
> > >>>   cmds/receive-dump.c | 1 -
> > >>>   kerncompat.h        | 4 ++++
> > >>>   2 files changed, 4 insertions(+), 1 deletion(-)
> > >>>
> > >>> diff --git a/cmds/receive-dump.c b/cmds/receive-dump.c
> > >>> index 47a0a30e..00ad4fd1 100644
> > >>> --- a/cmds/receive-dump.c
> > >>> +++ b/cmds/receive-dump.c
> > >>> @@ -31,7 +31,6 @@
> > >>>   #include <stdlib.h>
> > >>>   #include <time.h>
> > >>>   #include <ctype.h>
> > >>> -#include <asm/types.h>
> > >>>   #include <uuid/uuid.h>
> > >>>   #include "common/utils.h"
> > >>>   #include "cmds/commands.h"
> > >>> diff --git a/kerncompat.h b/kerncompat.h
> > >>> index 6ca1526e..4b36b45a 100644
> > >>> --- a/kerncompat.h
> > >>> +++ b/kerncompat.h
> > >>> @@ -19,6 +19,10 @@
> > >>>   #ifndef __KERNCOMPAT_H__
> > >>>   #define __KERNCOMPAT_H__
> > >>>
> > >>> +#ifndef __SANE_USERSPACE_TYPES__
> > >>> +#define __SANE_USERSPACE_TYPES__     /* For PPC64, to get LL64 types */
> > >>> +#endif
> > >>
> > >> Is there a cleaner way instead of defining magic macros?
> > > no. https://github.com/torvalds/linux/blob/master/arch/powerpc/include/uapi/asm/types.h#L18
> >
> > Really?
> >
> > I have the same issue in btrfs-fuse, but it can be easily solved without
> > using the magic macro.
> >
> > See this issue:
> >
> > https://github.com/adam900710/btrfs-fuse/issues/2
> >
> > including <linux/types.h> seems to solve it for btrfs-fuse.
>
> Ok, so it's just the asm/types.h, once it's deleted it should all work
> with linux/types.h (included via kerncompat.h).
Qu is referring to a different issue. I am referring to bad printf formats.
>
> Rosen, could you please verify that this is sufficient (without the
> extra macro)?
It is not.

Also note that this is specific to ppc64 and mips64. and alpha
(whatever that is).

a git grep of the linux tree for that macro shows that it's used in tools/

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] btrfs-progs: fix 64-bit mips and powerpc types
  2022-02-02  0:11         ` Rosen Penev
@ 2022-02-02  0:31           ` Qu Wenruo
  2022-02-02  0:35             ` Rosen Penev
  2022-02-04 18:40           ` David Sterba
  1 sibling, 1 reply; 10+ messages in thread
From: Qu Wenruo @ 2022-02-02  0:31 UTC (permalink / raw)
  To: Rosen Penev, dsterba, linux-btrfs



On 2022/2/2 08:11, Rosen Penev wrote:
> On Tue, Feb 1, 2022 at 5:44 AM David Sterba <dsterba@suse.cz> wrote:
>>
>> On Tue, Feb 01, 2022 at 08:58:55PM +0800, Qu Wenruo wrote:
>>>
>>>
>>> On 2022/2/1 04:46, Rosen Penev wrote:
>>>> On Mon, Jan 31, 2022 at 6:40 AM David Sterba <dsterba@suse.cz> wrote:
>>>>>
>>>>> On Sat, Jan 29, 2022 at 05:09:56PM -0800, Rosen Penev wrote:
>>>>>> The kernel uses unsigned long specifically for ppc64 and mips64. This
>>>>>> fixes that.
>>>>>
>>>>> What do you mean? Uses unsigned long for what?
>>>> kernel's u64 is normally unsigned long long, but not for ppc64 and mips64.
>>>>>
>>>>>> Removed asm/types.h include as it will get included properly later.
>>>>>>
>>>>>> Fixes -Wformat warnings.
>>>>>>
>>>>>> Signed-off-by: Rosen Penev <rosenp@gmail.com>
>>>>>> ---
>>>>>>    cmds/receive-dump.c | 1 -
>>>>>>    kerncompat.h        | 4 ++++
>>>>>>    2 files changed, 4 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/cmds/receive-dump.c b/cmds/receive-dump.c
>>>>>> index 47a0a30e..00ad4fd1 100644
>>>>>> --- a/cmds/receive-dump.c
>>>>>> +++ b/cmds/receive-dump.c
>>>>>> @@ -31,7 +31,6 @@
>>>>>>    #include <stdlib.h>
>>>>>>    #include <time.h>
>>>>>>    #include <ctype.h>
>>>>>> -#include <asm/types.h>
>>>>>>    #include <uuid/uuid.h>
>>>>>>    #include "common/utils.h"
>>>>>>    #include "cmds/commands.h"
>>>>>> diff --git a/kerncompat.h b/kerncompat.h
>>>>>> index 6ca1526e..4b36b45a 100644
>>>>>> --- a/kerncompat.h
>>>>>> +++ b/kerncompat.h
>>>>>> @@ -19,6 +19,10 @@
>>>>>>    #ifndef __KERNCOMPAT_H__
>>>>>>    #define __KERNCOMPAT_H__
>>>>>>
>>>>>> +#ifndef __SANE_USERSPACE_TYPES__
>>>>>> +#define __SANE_USERSPACE_TYPES__     /* For PPC64, to get LL64 types */
>>>>>> +#endif
>>>>>
>>>>> Is there a cleaner way instead of defining magic macros?
>>>> no. https://github.com/torvalds/linux/blob/master/arch/powerpc/include/uapi/asm/types.h#L18
>>>
>>> Really?
>>>
>>> I have the same issue in btrfs-fuse, but it can be easily solved without
>>> using the magic macro.
>>>
>>> See this issue:
>>>
>>> https://github.com/adam900710/btrfs-fuse/issues/2
>>>
>>> including <linux/types.h> seems to solve it for btrfs-fuse.
>>
>> Ok, so it's just the asm/types.h, once it's deleted it should all work
>> with linux/types.h (included via kerncompat.h).
> Qu is referring to a different issue. I am referring to bad printf formats.

Weird, as the report includes format '%llu' warning for printf formats.

>>
>> Rosen, could you please verify that this is sufficient (without the
>> extra macro)?
> It is not.
>
> Also note that this is specific to ppc64 and mips64. and alpha
> (whatever that is).
>
> a git grep of the linux tree for that macro shows that it's used in tools/

OK, after checking the latest build log from Fedora36 ppc64le, it indeed
still shows the warning:

https://kojipkgs.fedoraproject.org//packages/btrfs-fuse/0/6.20211113git8635fbc.fc36/data/logs/ppc64le/build.log


Although from what I see, that magic is more common set for packaging,
not directly into the source code:

https://chromium.googlesource.com/chromium/src.git/+/7d38bae3ef691d5091b6d4d7973a9b4d2cd85eb2/build/config/compiler/BUILD.gn#988

Where chromium choose to add that magic only for mips64

Or this:

https://github.com/LLNL/lustre/blob/2.12.7-llnl/lustre.spec.in#L343

Which is only defined during packaging, not in the source code.


We can put this into our Makefile, and only for affected archtectures then.

Thanks,
Qu

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] btrfs-progs: fix 64-bit mips and powerpc types
  2022-02-02  0:31           ` Qu Wenruo
@ 2022-02-02  0:35             ` Rosen Penev
  2022-02-02  0:40               ` Qu Wenruo
  0 siblings, 1 reply; 10+ messages in thread
From: Rosen Penev @ 2022-02-02  0:35 UTC (permalink / raw)
  To: Qu Wenruo; +Cc: dsterba, linux-btrfs

On Tue, Feb 1, 2022 at 4:31 PM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>
>
>
> On 2022/2/2 08:11, Rosen Penev wrote:
> > On Tue, Feb 1, 2022 at 5:44 AM David Sterba <dsterba@suse.cz> wrote:
> >>
> >> On Tue, Feb 01, 2022 at 08:58:55PM +0800, Qu Wenruo wrote:
> >>>
> >>>
> >>> On 2022/2/1 04:46, Rosen Penev wrote:
> >>>> On Mon, Jan 31, 2022 at 6:40 AM David Sterba <dsterba@suse.cz> wrote:
> >>>>>
> >>>>> On Sat, Jan 29, 2022 at 05:09:56PM -0800, Rosen Penev wrote:
> >>>>>> The kernel uses unsigned long specifically for ppc64 and mips64. This
> >>>>>> fixes that.
> >>>>>
> >>>>> What do you mean? Uses unsigned long for what?
> >>>> kernel's u64 is normally unsigned long long, but not for ppc64 and mips64.
> >>>>>
> >>>>>> Removed asm/types.h include as it will get included properly later.
> >>>>>>
> >>>>>> Fixes -Wformat warnings.
> >>>>>>
> >>>>>> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> >>>>>> ---
> >>>>>>    cmds/receive-dump.c | 1 -
> >>>>>>    kerncompat.h        | 4 ++++
> >>>>>>    2 files changed, 4 insertions(+), 1 deletion(-)
> >>>>>>
> >>>>>> diff --git a/cmds/receive-dump.c b/cmds/receive-dump.c
> >>>>>> index 47a0a30e..00ad4fd1 100644
> >>>>>> --- a/cmds/receive-dump.c
> >>>>>> +++ b/cmds/receive-dump.c
> >>>>>> @@ -31,7 +31,6 @@
> >>>>>>    #include <stdlib.h>
> >>>>>>    #include <time.h>
> >>>>>>    #include <ctype.h>
> >>>>>> -#include <asm/types.h>
> >>>>>>    #include <uuid/uuid.h>
> >>>>>>    #include "common/utils.h"
> >>>>>>    #include "cmds/commands.h"
> >>>>>> diff --git a/kerncompat.h b/kerncompat.h
> >>>>>> index 6ca1526e..4b36b45a 100644
> >>>>>> --- a/kerncompat.h
> >>>>>> +++ b/kerncompat.h
> >>>>>> @@ -19,6 +19,10 @@
> >>>>>>    #ifndef __KERNCOMPAT_H__
> >>>>>>    #define __KERNCOMPAT_H__
> >>>>>>
> >>>>>> +#ifndef __SANE_USERSPACE_TYPES__
> >>>>>> +#define __SANE_USERSPACE_TYPES__     /* For PPC64, to get LL64 types */
> >>>>>> +#endif
> >>>>>
> >>>>> Is there a cleaner way instead of defining magic macros?
> >>>> no. https://github.com/torvalds/linux/blob/master/arch/powerpc/include/uapi/asm/types.h#L18
> >>>
> >>> Really?
> >>>
> >>> I have the same issue in btrfs-fuse, but it can be easily solved without
> >>> using the magic macro.
> >>>
> >>> See this issue:
> >>>
> >>> https://github.com/adam900710/btrfs-fuse/issues/2
> >>>
> >>> including <linux/types.h> seems to solve it for btrfs-fuse.
> >>
> >> Ok, so it's just the asm/types.h, once it's deleted it should all work
> >> with linux/types.h (included via kerncompat.h).
> > Qu is referring to a different issue. I am referring to bad printf formats.
>
> Weird, as the report includes format '%llu' warning for printf formats.
>
> >>
> >> Rosen, could you please verify that this is sufficient (without the
> >> extra macro)?
> > It is not.
> >
> > Also note that this is specific to ppc64 and mips64. and alpha
> > (whatever that is).
> >
> > a git grep of the linux tree for that macro shows that it's used in tools/
>
> OK, after checking the latest build log from Fedora36 ppc64le, it indeed
> still shows the warning:
>
> https://kojipkgs.fedoraproject.org//packages/btrfs-fuse/0/6.20211113git8635fbc.fc36/data/logs/ppc64le/build.log
>
>
> Although from what I see, that magic is more common set for packaging,
> not directly into the source code:
OTOH tools/perf and some tests define this macro.
>
> https://chromium.googlesource.com/chromium/src.git/+/7d38bae3ef691d5091b6d4d7973a9b4d2cd85eb2/build/config/compiler/BUILD.gn#988
>
> Where chromium choose to add that magic only for mips64
>
> Or this:
>
> https://github.com/LLNL/lustre/blob/2.12.7-llnl/lustre.spec.in#L343
>
> Which is only defined during packaging, not in the source code.
>
>
> We can put this into our Makefile, and only for affected archtectures then.
>
> Thanks,
> Qu

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] btrfs-progs: fix 64-bit mips and powerpc types
  2022-02-02  0:35             ` Rosen Penev
@ 2022-02-02  0:40               ` Qu Wenruo
  0 siblings, 0 replies; 10+ messages in thread
From: Qu Wenruo @ 2022-02-02  0:40 UTC (permalink / raw)
  To: Rosen Penev; +Cc: dsterba, linux-btrfs



On 2022/2/2 08:35, Rosen Penev wrote:
> On Tue, Feb 1, 2022 at 4:31 PM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>
>>
>>
>> On 2022/2/2 08:11, Rosen Penev wrote:
>>> On Tue, Feb 1, 2022 at 5:44 AM David Sterba <dsterba@suse.cz> wrote:
>>>>
>>>> On Tue, Feb 01, 2022 at 08:58:55PM +0800, Qu Wenruo wrote:
>>>>>
>>>>>
>>>>> On 2022/2/1 04:46, Rosen Penev wrote:
>>>>>> On Mon, Jan 31, 2022 at 6:40 AM David Sterba <dsterba@suse.cz> wrote:
>>>>>>>
>>>>>>> On Sat, Jan 29, 2022 at 05:09:56PM -0800, Rosen Penev wrote:
>>>>>>>> The kernel uses unsigned long specifically for ppc64 and mips64. This
>>>>>>>> fixes that.
>>>>>>>
>>>>>>> What do you mean? Uses unsigned long for what?
>>>>>> kernel's u64 is normally unsigned long long, but not for ppc64 and mips64.
>>>>>>>
>>>>>>>> Removed asm/types.h include as it will get included properly later.
>>>>>>>>
>>>>>>>> Fixes -Wformat warnings.
>>>>>>>>
>>>>>>>> Signed-off-by: Rosen Penev <rosenp@gmail.com>
>>>>>>>> ---
>>>>>>>>     cmds/receive-dump.c | 1 -
>>>>>>>>     kerncompat.h        | 4 ++++
>>>>>>>>     2 files changed, 4 insertions(+), 1 deletion(-)
>>>>>>>>
>>>>>>>> diff --git a/cmds/receive-dump.c b/cmds/receive-dump.c
>>>>>>>> index 47a0a30e..00ad4fd1 100644
>>>>>>>> --- a/cmds/receive-dump.c
>>>>>>>> +++ b/cmds/receive-dump.c
>>>>>>>> @@ -31,7 +31,6 @@
>>>>>>>>     #include <stdlib.h>
>>>>>>>>     #include <time.h>
>>>>>>>>     #include <ctype.h>
>>>>>>>> -#include <asm/types.h>
>>>>>>>>     #include <uuid/uuid.h>
>>>>>>>>     #include "common/utils.h"
>>>>>>>>     #include "cmds/commands.h"
>>>>>>>> diff --git a/kerncompat.h b/kerncompat.h
>>>>>>>> index 6ca1526e..4b36b45a 100644
>>>>>>>> --- a/kerncompat.h
>>>>>>>> +++ b/kerncompat.h
>>>>>>>> @@ -19,6 +19,10 @@
>>>>>>>>     #ifndef __KERNCOMPAT_H__
>>>>>>>>     #define __KERNCOMPAT_H__
>>>>>>>>
>>>>>>>> +#ifndef __SANE_USERSPACE_TYPES__
>>>>>>>> +#define __SANE_USERSPACE_TYPES__     /* For PPC64, to get LL64 types */
>>>>>>>> +#endif
>>>>>>>
>>>>>>> Is there a cleaner way instead of defining magic macros?
>>>>>> no. https://github.com/torvalds/linux/blob/master/arch/powerpc/include/uapi/asm/types.h#L18
>>>>>
>>>>> Really?
>>>>>
>>>>> I have the same issue in btrfs-fuse, but it can be easily solved without
>>>>> using the magic macro.
>>>>>
>>>>> See this issue:
>>>>>
>>>>> https://github.com/adam900710/btrfs-fuse/issues/2
>>>>>
>>>>> including <linux/types.h> seems to solve it for btrfs-fuse.
>>>>
>>>> Ok, so it's just the asm/types.h, once it's deleted it should all work
>>>> with linux/types.h (included via kerncompat.h).
>>> Qu is referring to a different issue. I am referring to bad printf formats.
>>
>> Weird, as the report includes format '%llu' warning for printf formats.
>>
>>>>
>>>> Rosen, could you please verify that this is sufficient (without the
>>>> extra macro)?
>>> It is not.
>>>
>>> Also note that this is specific to ppc64 and mips64. and alpha
>>> (whatever that is).
>>>
>>> a git grep of the linux tree for that macro shows that it's used in tools/
>>
>> OK, after checking the latest build log from Fedora36 ppc64le, it indeed
>> still shows the warning:
>>
>> https://kojipkgs.fedoraproject.org//packages/btrfs-fuse/0/6.20211113git8635fbc.fc36/data/logs/ppc64le/build.log
>>
>>
>> Although from what I see, that magic is more common set for packaging,
>> not directly into the source code:
> OTOH tools/perf and some tests define this macro.

That's a trade-off between easier to package and easier to read.

Although as mentioned, it seems more common to define it at packaging time.

Personally I'm fine with both way, but a little more towards defined in
Makefile.

(Also my time to update btrfs-fuse to handle the build warning)

Thanks,
Qu
>>
>> https://chromium.googlesource.com/chromium/src.git/+/7d38bae3ef691d5091b6d4d7973a9b4d2cd85eb2/build/config/compiler/BUILD.gn#988
>>
>> Where chromium choose to add that magic only for mips64
>>
>> Or this:
>>
>> https://github.com/LLNL/lustre/blob/2.12.7-llnl/lustre.spec.in#L343
>>
>> Which is only defined during packaging, not in the source code.
>>
>>
>> We can put this into our Makefile, and only for affected archtectures then.
>>
>> Thanks,
>> Qu

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] btrfs-progs: fix 64-bit mips and powerpc types
  2022-02-02  0:11         ` Rosen Penev
  2022-02-02  0:31           ` Qu Wenruo
@ 2022-02-04 18:40           ` David Sterba
  1 sibling, 0 replies; 10+ messages in thread
From: David Sterba @ 2022-02-04 18:40 UTC (permalink / raw)
  To: Rosen Penev; +Cc: dsterba, Qu Wenruo, linux-btrfs

On Tue, Feb 01, 2022 at 04:11:25PM -0800, Rosen Penev wrote:
> > > >>> +#ifndef __SANE_USERSPACE_TYPES__
> > > >>> +#define __SANE_USERSPACE_TYPES__     /* For PPC64, to get LL64 types */
> > > >>> +#endif
> > > >>
> > > >> Is there a cleaner way instead of defining magic macros?
> > > > no. https://github.com/torvalds/linux/blob/master/arch/powerpc/include/uapi/asm/types.h#L18
> > >
> > > Really?
> > >
> > > I have the same issue in btrfs-fuse, but it can be easily solved without
> > > using the magic macro.
> > >
> > > See this issue:
> > >
> > > https://github.com/adam900710/btrfs-fuse/issues/2
> > >
> > > including <linux/types.h> seems to solve it for btrfs-fuse.
> >
> > Ok, so it's just the asm/types.h, once it's deleted it should all work
> > with linux/types.h (included via kerncompat.h).
> Qu is referring to a different issue. I am referring to bad printf formats.
> >
> > Rosen, could you please verify that this is sufficient (without the
> > extra macro)?
> It is not.
> 
> Also note that this is specific to ppc64 and mips64. and alpha
> (whatever that is).
> 
> a git grep of the linux tree for that macro shows that it's used in tools/

Ok, let's use the magic macro.

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2022-02-04 18:41 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-30  1:09 [PATCH] btrfs-progs: fix 64-bit mips and powerpc types Rosen Penev
2022-01-31 14:39 ` David Sterba
2022-01-31 20:46   ` Rosen Penev
2022-02-01 12:58     ` Qu Wenruo
2022-02-01 13:44       ` David Sterba
2022-02-02  0:11         ` Rosen Penev
2022-02-02  0:31           ` Qu Wenruo
2022-02-02  0:35             ` Rosen Penev
2022-02-02  0:40               ` Qu Wenruo
2022-02-04 18:40           ` David Sterba

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.