* Linus Torvalds <torva...@linux-foundation.org> wrote:
> On Sat, Apr 20, 2019 at 12:30 AM Ingo Molnar <mi...@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
