lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAKaJLVum=eOgsnsaoNzp4WJ7NpAekeuKH2C8Cbk57z0Oy0GM=w@mail.gmail.com>
Date:   Wed, 9 Jan 2019 17:45:59 +0200
From:   Sam Protsenko <semen.protsenko@...aro.org>
To:     Jan Harkes <jaharkes@...cmu.edu>
Cc:     hch@....de, Andrew Morton <akpm@...ux-foundation.org>,
        kernel-janitors@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-scsi@...r.kernel.org, Praneeth Bajjuri <praneeth@...com>,
        Ruslan Bilovol <ruslan.bilovol@...il.com>,
        Andy Shevchenko <andy.shevchenko@...il.com>
Subject: Re: [PATCH v2] codafs: Fix build using bare-metal toolchain

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ