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@xxxxxxxxxx> wrote: > > That actually makes a lot of sense. > > Jan > > On November 21, 2018 2:39:03 PM EST, Sam Protsenko <semen.protsenko@xxxxxxxxxx> wrote: > >+ Jan Harkes back to "To:" list, slipped away somehow... > > > >On Wed, Nov 21, 2018 at 9:36 PM Sam Protsenko > ><semen.protsenko@xxxxxxxxxx> wrote: > >> > >> On Wed, Nov 21, 2018 at 8:10 PM Jan Harkes <jaharkes@xxxxxxxxxx> > >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 > >> >
