lkml.org 
[lkml]   [2019]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT PULL] locking fixes

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Sat, Apr 20, 2019 at 12:30 AM Ingo Molnar <mingo@kernel.org> wrote:
> >
> > A lockdep warning fix and a script execution fix when atomics are
> > generated.
>
> Hmm. I've pulled this, but looking at it, I think it's worth noting something...
>
> > diff --git a/scripts/atomic/gen-atomics.sh b/scripts/atomic/gen-atomics.sh
> > index 27400b0cd732..000dc6437893 100644
> > --- a/scripts/atomic/gen-atomics.sh
> > +++ b/scripts/atomic/gen-atomics.sh
> > - ${ATOMICDIR}/${script} ${ATOMICTBL} > ${LINUXDIR}/include/${header}
> > + /bin/sh ${ATOMICDIR}/${script} ${ATOMICTBL} > ${LINUXDIR}/include/${header}
>
> /bin/sh ?
>
> Yes, that's what the hash-bang line says in the scripts themselves,
> and thus what we used to do with the whole direct execution thing, so
> it's clearly not _wrong_, but every single time when we manually do
> the "run with shell" normally, we use $(CONFIG_SHELL)".
>
> So I get the feeling that we should likely do that here too.
>
> Of course, the gen-atomics script is (now) outside the normal build,
> so maybe people just go "this is special, doesn't go through the
> normal build process anyway, and thus might as well not follow the
> common rules".

Yeah, agreed that this is all a bit weird. The status quo right now is:

- scripts/atomic/gen-atomics.sh is a completely standalone, external
script which isn't even tied into any Makefile mechanism to build the
kernel.

- To generate the headers one has to explicitly call
scripts/atomic/gen-atomics.sh, and it's not even executable, so the
incantation is even more weird:

$ . scripts/atomic/gen-atomics.sh

So I agree that the UI of all this should be improved, I suspect we
should do the following improvements:

- make gen-atomics.sh executable

- add a "make headers_gen_atomics" target to the main Makefile

- call gen-atomics.sh via the build system and thus have access to
$CONFIG_SHELL and such and don't have assumptions about the shell
environment.

Arguably /bin/sh tends to exist during the build, everywhere. What
usually results in the use of CONFIG_SHELL isn't /bin/sh per se but
specific shell variant assumptions such as /bin/bash and the resulting
occasional Bashism in the scripts - there are systems with non-bash
shells by default and so.

Thanks,

Ingo

\
 
 \ /
  Last update: 2019-04-21 20:24    [W:0.069 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site