The kernel is self-contained project and can be built with bare-metal
toolchain. But bare-metal toolchain doesn't define __linux__. Because of
this u_quad_t type is not defined when using bare-metal toolchain and
codafs build fails. This patch fixes it by defining u_quad_t type
unconditionally.
Cc: Jan Harkes <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Cc: Andy Shevchenko <[email protected]>
Signed-off-by: Sam Protsenko <[email protected]>
---
include/linux/coda.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/linux/coda.h b/include/linux/coda.h
index d30209b9cef8..0ca0c83fdb1c 100644
--- a/include/linux/coda.h
+++ b/include/linux/coda.h
@@ -58,8 +58,7 @@ Mellon the rights to redistribute these changes without encumbrance.
#ifndef _CODA_HEADER_
#define _CODA_HEADER_
-#if defined(__linux__)
typedef unsigned long long u_quad_t;
-#endif
+
#include <uapi/linux/coda.h>
#endif
--
2.19.1
On Tue, Oct 30, 2018 at 10:27 PM Sam Protsenko
<[email protected]> wrote:
>
> The kernel is self-contained project and can be built with bare-metal
> toolchain. But bare-metal toolchain doesn't define __linux__. Because of
> this u_quad_t type is not defined when using bare-metal toolchain and
> codafs build fails. This patch fixes it by defining u_quad_t type
> unconditionally.
>
> Cc: Jan Harkes <[email protected]>
> Cc: Christoph Hellwig <[email protected]>
> Cc: Andy Shevchenko <[email protected]>
> Signed-off-by: Sam Protsenko <[email protected]>
> ---
> include/linux/coda.h | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/include/linux/coda.h b/include/linux/coda.h
> index d30209b9cef8..0ca0c83fdb1c 100644
> --- a/include/linux/coda.h
> +++ b/include/linux/coda.h
> @@ -58,8 +58,7 @@ Mellon the rights to redistribute these changes without encumbrance.
> #ifndef _CODA_HEADER_
> #define _CODA_HEADER_
>
> -#if defined(__linux__)
> typedef unsigned long long u_quad_t;
> -#endif
> +
> #include <uapi/linux/coda.h>
> #endif
> --
> 2.19.1
>
+ Jan Harkes, + Ruslan Bilovol
Hi Jan,
Can you please apply this? Nobody seems to be interested in taking
this patch, so I'm not sure how to proceed further. Please advice.
Thanks!
On Wed, Nov 21, 2018 at 6:31 PM Sam Protsenko
<[email protected]> wrote:
>
> On Tue, Oct 30, 2018 at 10:27 PM Sam Protsenko
> <[email protected]> wrote:
> >
> > The kernel is self-contained project and can be built with bare-metal
> > toolchain. But bare-metal toolchain doesn't define __linux__. Because of
> > this u_quad_t type is not defined when using bare-metal toolchain and
> > codafs build fails. This patch fixes it by defining u_quad_t type
> > unconditionally.
> >
> > Cc: Jan Harkes <[email protected]>
> > Cc: Christoph Hellwig <[email protected]>
> > Cc: Andy Shevchenko <[email protected]>
I'm not sure how you managed to miss people in this list (perhaps by
default you have suppress all Cc in your Git configuration), but I
guess we may gently ask Christoph to apply this in case Jan will not
appear.
> > Signed-off-by: Sam Protsenko <[email protected]>
> > ---
> > include/linux/coda.h | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/include/linux/coda.h b/include/linux/coda.h
> > index d30209b9cef8..0ca0c83fdb1c 100644
> > --- a/include/linux/coda.h
> > +++ b/include/linux/coda.h
> > @@ -58,8 +58,7 @@ Mellon the rights to redistribute these changes without encumbrance.
> > #ifndef _CODA_HEADER_
> > #define _CODA_HEADER_
> >
> > -#if defined(__linux__)
> > typedef unsigned long long u_quad_t;
> > -#endif
> > +
> > #include <uapi/linux/coda.h>
> > #endif
> > --
> > 2.19.1
> >
>
> + Jan Harkes, + Ruslan Bilovol
>
> Hi Jan,
>
> Can you please apply this? Nobody seems to be interested in taking
> this patch, so I'm not sure how to proceed further. Please advice.
>
> Thanks!
--
With Best Regards,
Andy Shevchenko
On Wed, Nov 21, 2018 at 06:41:13PM +0200, Andy Shevchenko wrote:
> I'm not sure how you managed to miss people in this list (perhaps by
> default you have suppress all Cc in your Git configuration), but I
> guess we may gently ask Christoph to apply this in case Jan will not
> appear.
I don't really have a relevant tree. You probably want to send it
to Al Viro.
On Wed, Nov 21, 2018 at 06:41:13PM +0200, Andy Shevchenko wrote:
> I'm not sure how you managed to miss people in this list (perhaps by
> default you have suppress all Cc in your Git configuration), but I
> guess we may gently ask Christoph to apply this in case Jan will not
> appear.
You have got to give me a little more than 10 minutes to respond before
assuming that I would not appear... I don't think I've ignored any
previous emails on this subject and the only issues has been some people
not receiving my responses for unknown reasons (agressive spam filter?).
I have no problem with this patch, have it sitting with some other
non-urgent patches and in case it doesn't appear upstream it should
piggyback with whatever I have to send.
I still don't know why the bare-metal toolchain couldn't just add a
-D__linux__. I understand that this define is expected to be always
present while compiling kernel headers so that there is no good reason
to even bother testing for it, which is why I have no issue with the
patch. But it seems it would make your life a lot easier if you had it
defined.
Jan
On Wed, Nov 21, 2018 at 8:10 PM Jan Harkes <[email protected]> wrote:
>
> On Wed, Nov 21, 2018 at 06:41:13PM +0200, Andy Shevchenko wrote:
> > I'm not sure how you managed to miss people in this list (perhaps by
> > default you have suppress all Cc in your Git configuration), but I
> > guess we may gently ask Christoph to apply this in case Jan will not
> > appear.
>
> You have got to give me a little more than 10 minutes to respond before
> assuming that I would not appear... I don't think I've ignored any
> previous emails on this subject and the only issues has been some people
> not receiving my responses for unknown reasons (agressive spam filter?).
>
> I have no problem with this patch, have it sitting with some other
> non-urgent patches and in case it doesn't appear upstream it should
> piggyback with whatever I have to send.
>
Thanks, Jan, really appreciate it. We need this patch to fix our tests
with allmodconfig configuration (in Linaro CI loops).
> I still don't know why the bare-metal toolchain couldn't just add a
> -D__linux__. I understand that this define is expected to be always
> present while compiling kernel headers so that there is no good reason
> to even bother testing for it, which is why I have no issue with the
> patch. But it seems it would make your life a lot easier if you had it
> defined.
>
As I understand it, from toolchain's point of view, if __linux__ is
defined then it means that the program is being built *for* Linux
(i.e. we can use Linux specific features, ABI, like syscalls).
Checking this definition can make sense in uapi headers, but in kernel
code we shouldn't use it (as kernel is baremetal program and not
compiled for some OS). I presume that's why __linux__ is not defined
in bare-metal toolchains (as those don't provide Linux specific
features, libc, etc).
> Jan
>
+ Jan Harkes back to "To:" list, slipped away somehow...
On Wed, Nov 21, 2018 at 9:36 PM Sam Protsenko
<[email protected]> wrote:
>
> On Wed, Nov 21, 2018 at 8:10 PM Jan Harkes <[email protected]> wrote:
> >
> > On Wed, Nov 21, 2018 at 06:41:13PM +0200, Andy Shevchenko wrote:
> > > I'm not sure how you managed to miss people in this list (perhaps by
> > > default you have suppress all Cc in your Git configuration), but I
> > > guess we may gently ask Christoph to apply this in case Jan will not
> > > appear.
> >
> > You have got to give me a little more than 10 minutes to respond before
> > assuming that I would not appear... I don't think I've ignored any
> > previous emails on this subject and the only issues has been some people
> > not receiving my responses for unknown reasons (agressive spam filter?).
> >
> > I have no problem with this patch, have it sitting with some other
> > non-urgent patches and in case it doesn't appear upstream it should
> > piggyback with whatever I have to send.
> >
>
> Thanks, Jan, really appreciate it. We need this patch to fix our tests
> with allmodconfig configuration (in Linaro CI loops).
>
> > I still don't know why the bare-metal toolchain couldn't just add a
> > -D__linux__. I understand that this define is expected to be always
> > present while compiling kernel headers so that there is no good reason
> > to even bother testing for it, which is why I have no issue with the
> > patch. But it seems it would make your life a lot easier if you had it
> > defined.
> >
>
> As I understand it, from toolchain's point of view, if __linux__ is
> defined then it means that the program is being built *for* Linux
> (i.e. we can use Linux specific features, ABI, like syscalls).
> Checking this definition can make sense in uapi headers, but in kernel
> code we shouldn't use it (as kernel is baremetal program and not
> compiled for some OS). I presume that's why __linux__ is not defined
> in bare-metal toolchains (as those don't provide Linux specific
> features, libc, etc).
>
> > Jan
> >
That actually makes a lot of sense.
Jan
On November 21, 2018 2:39:03 PM EST, Sam Protsenko <[email protected]> wrote:
>+ Jan Harkes back to "To:" list, slipped away somehow...
>
>On Wed, Nov 21, 2018 at 9:36 PM Sam Protsenko
><[email protected]> wrote:
>>
>> On Wed, Nov 21, 2018 at 8:10 PM Jan Harkes <[email protected]>
>wrote:
>> >
>> > On Wed, Nov 21, 2018 at 06:41:13PM +0200, Andy Shevchenko wrote:
>> > > I'm not sure how you managed to miss people in this list (perhaps
>by
>> > > default you have suppress all Cc in your Git configuration), but
>I
>> > > guess we may gently ask Christoph to apply this in case Jan will
>not
>> > > appear.
>> >
>> > You have got to give me a little more than 10 minutes to respond
>before
>> > assuming that I would not appear... I don't think I've ignored any
>> > previous emails on this subject and the only issues has been some
>people
>> > not receiving my responses for unknown reasons (agressive spam
>filter?).
>> >
>> > I have no problem with this patch, have it sitting with some other
>> > non-urgent patches and in case it doesn't appear upstream it should
>> > piggyback with whatever I have to send.
>> >
>>
>> Thanks, Jan, really appreciate it. We need this patch to fix our
>tests
>> with allmodconfig configuration (in Linaro CI loops).
>>
>> > I still don't know why the bare-metal toolchain couldn't just add a
>> > -D__linux__. I understand that this define is expected to be
>always
>> > present while compiling kernel headers so that there is no good
>reason
>> > to even bother testing for it, which is why I have no issue with
>the
>> > patch. But it seems it would make your life a lot easier if you had
>it
>> > defined.
>> >
>>
>> As I understand it, from toolchain's point of view, if __linux__ is
>> defined then it means that the program is being built *for* Linux
>> (i.e. we can use Linux specific features, ABI, like syscalls).
>> Checking this definition can make sense in uapi headers, but in
>kernel
>> code we shouldn't use it (as kernel is baremetal program and not
>> compiled for some OS). I presume that's why __linux__ is not defined
>> in bare-metal toolchains (as those don't provide Linux specific
>> features, libc, etc).
>>
>> > Jan
>> >
On Wed, Nov 21, 2018 at 8:10 PM Jan Harkes <[email protected]> wrote:
>
> On Wed, Nov 21, 2018 at 06:41:13PM +0200, Andy Shevchenko wrote:
> > I'm not sure how you managed to miss people in this list (perhaps by
> > default you have suppress all Cc in your Git configuration), but I
> > guess we may gently ask Christoph to apply this in case Jan will not
> > appear.
>
> You have got to give me a little more than 10 minutes to respond before
> assuming that I would not appear...
Problem is, AFAICS, Sam's initial Cc list was not fulfilled. As I
guessed it might be configuration issue on his side.
> I don't think I've ignored any
> previous emails on this subject and the only issues has been some people
> not receiving my responses for unknown reasons (agressive spam filter?).
Personally I didn't get this one (Gmail "clever" spam filtering).
--
With Best Regards,
Andy Shevchenko
Hi Jan,
Can you please clarify on this patch? As I can see v5.0-rc1 is out
now, which means merge window is closed, but I can't see this patch in
linux-mainline yet. Do you need any additional steps from my side
(like rebasing, etc)?
Thanks!
On Thu, Nov 22, 2018 at 12:49 AM Jan Harkes <[email protected]> wrote:
>
> That actually makes a lot of sense.
>
> Jan
>
> On November 21, 2018 2:39:03 PM EST, Sam Protsenko <[email protected]> wrote:
> >+ Jan Harkes back to "To:" list, slipped away somehow...
> >
> >On Wed, Nov 21, 2018 at 9:36 PM Sam Protsenko
> ><[email protected]> wrote:
> >>
> >> On Wed, Nov 21, 2018 at 8:10 PM Jan Harkes <[email protected]>
> >wrote:
> >> >
> >> > On Wed, Nov 21, 2018 at 06:41:13PM +0200, Andy Shevchenko wrote:
> >> > > I'm not sure how you managed to miss people in this list (perhaps
> >by
> >> > > default you have suppress all Cc in your Git configuration), but
> >I
> >> > > guess we may gently ask Christoph to apply this in case Jan will
> >not
> >> > > appear.
> >> >
> >> > You have got to give me a little more than 10 minutes to respond
> >before
> >> > assuming that I would not appear... I don't think I've ignored any
> >> > previous emails on this subject and the only issues has been some
> >people
> >> > not receiving my responses for unknown reasons (agressive spam
> >filter?).
> >> >
> >> > I have no problem with this patch, have it sitting with some other
> >> > non-urgent patches and in case it doesn't appear upstream it should
> >> > piggyback with whatever I have to send.
> >> >
> >>
> >> Thanks, Jan, really appreciate it. We need this patch to fix our
> >tests
> >> with allmodconfig configuration (in Linaro CI loops).
> >>
> >> > I still don't know why the bare-metal toolchain couldn't just add a
> >> > -D__linux__. I understand that this define is expected to be
> >always
> >> > present while compiling kernel headers so that there is no good
> >reason
> >> > to even bother testing for it, which is why I have no issue with
> >the
> >> > patch. But it seems it would make your life a lot easier if you had
> >it
> >> > defined.
> >> >
> >>
> >> As I understand it, from toolchain's point of view, if __linux__ is
> >> defined then it means that the program is being built *for* Linux
> >> (i.e. we can use Linux specific features, ABI, like syscalls).
> >> Checking this definition can make sense in uapi headers, but in
> >kernel
> >> code we shouldn't use it (as kernel is baremetal program and not
> >> compiled for some OS). I presume that's why __linux__ is not defined
> >> in bare-metal toolchains (as those don't provide Linux specific
> >> features, libc, etc).
> >>
> >> > Jan
> >> >