| Message ID | 20181030202713.26203-1-semen.protsenko@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | [v2] codafs: Fix build using bare-metal toolchain | expand |
On Wed, Nov 21, 2018 at 6:31 PM Sam Protsenko <semen.protsenko@linaro.org> wrote: > > On Tue, Oct 30, 2018 at 10:27 PM Sam Protsenko > <semen.protsenko@linaro.org> 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 <jaharkes@cs.cmu.edu> > > Cc: Christoph Hellwig <hch@infradead.org> > > Cc: Andy Shevchenko <andy.shevchenko@gmail.com> 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 <semen.protsenko@linaro.org> > > --- > > 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
+ Jan Harkes back to "To:" list, slipped away somehow... On Wed, Nov 21, 2018 at 9:36 PM Sam Protsenko <semen.protsenko@linaro.org> wrote: > > On Wed, Nov 21, 2018 at 8:10 PM Jan Harkes <jaharkes@cs.cmu.edu> 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 <semen.protsenko@linaro.org> wrote: >+ Jan Harkes back to "To:" list, slipped away somehow... > >On Wed, Nov 21, 2018 at 9:36 PM Sam Protsenko ><semen.protsenko@linaro.org> wrote: >> >> On Wed, Nov 21, 2018 at 8:10 PM Jan Harkes <jaharkes@cs.cmu.edu> >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 <jaharkes@cs.cmu.edu> 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 <jaharkes@cs.cmu.edu> wrote: > > That actually makes a lot of sense. > > Jan > > On November 21, 2018 2:39:03 PM EST, Sam Protsenko <semen.protsenko@linaro.org> wrote: > >+ Jan Harkes back to "To:" list, slipped away somehow... > > > >On Wed, Nov 21, 2018 at 9:36 PM Sam Protsenko > ><semen.protsenko@linaro.org> wrote: > >> > >> On Wed, Nov 21, 2018 at 8:10 PM Jan Harkes <jaharkes@cs.cmu.edu> > >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 > >> >
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
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 <jaharkes@cs.cmu.edu> Cc: Christoph Hellwig <hch@infradead.org> Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> --- include/linux/coda.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) -- 2.19.1