* [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.