.S_shipped unnecessary?

.S_shipped unnecessary?

[Jason A. Donenfeld]

Hi Ard, Eric, and others,

As promised, the next Zinc patchset will have less generated code! After a
bit of work with Andy and Samuel, I'll be bundling the perlasm.

One thing I'm wondering about, though, is the wisdom behind the current
.S_shipped pattern. Usually the _shipped is for big firmware blobs that are
hard (or impossible) to build independently. But in this case, the .S is
generated from the .pl significantly faster than gcc even compiles a basic
C file. And, since perl is needed to build the kernel anyway, it's not like
it will be impossible to find the right tools. Rather than clutter up commits
with the .pl _and_ the .S_shipped, what would you think if I just generated
the .S each time as an ordinary build artifact. AFAICT, this is fairly usual,
and it's hard to see downsides. Hence, why I'm writing this email: are there
any downsides to that?

Thanks,
Jason

Re: .S_shipped unnecessary?

[Ard Biesheuvel]

(+ Masahiro, kbuild ml)

On 8 November 2018 at 21:37, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> Hi Ard, Eric, and others,
>
> As promised, the next Zinc patchset will have less generated code! After a
> bit of work with Andy and Samuel, I'll be bundling the perlasm.
>

Wonderful! Any problems doing that for x86_64 ?

> One thing I'm wondering about, though, is the wisdom behind the current
> .S_shipped pattern. Usually the _shipped is for big firmware blobs that are
> hard (or impossible) to build independently. But in this case, the .S is
> generated from the .pl significantly faster than gcc even compiles a basic
> C file. And, since perl is needed to build the kernel anyway, it's not like
> it will be impossible to find the right tools. Rather than clutter up commits
> with the .pl _and_ the .S_shipped, what would you think if I just generated
> the .S each time as an ordinary build artifact. AFAICT, this is fairly usual,
> and it's hard to see downsides. Hence, why I'm writing this email: are there
> any downsides to that?
>

I agree 100%. When I added this the first time, it was at the request
of the ARM maintainer, who was reluctant to rely on Perl for some
reason.

Recently, we have had to add a kludge to prevent spurious rebuilds of
the .S_shipped files as well.

I'd be perfectly happy to get rid of this entirely, and always
generate the .S from the .pl, which to me is kind of the point of
carrying these files in the first place.

Masahiro: do you see any problems with this?

Re: .S_shipped unnecessary?

[Jason A. Donenfeld]

Hey Ard,

On Fri, Nov 9, 2018 at 12:42 AM Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> Wonderful! Any problems doing that for x86_64 ?

The x86_64 is still a WIP, but hopefully we'll succeed.

> I agree 100%. When I added this the first time, it was at the request
> of the ARM maintainer, who was reluctant to rely on Perl for some
> reason.
>
> Recently, we have had to add a kludge to prevent spurious rebuilds of
> the .S_shipped files as well.
>
> I'd be perfectly happy to get rid of this entirely, and always
> generate the .S from the .pl, which to me is kind of the point of
> carrying these files in the first place.

Terrific. I'll move ahead in that direction then. It makes things _so_
much cleaner, and doesn't introduce new build modes ("should the
generated _ship go into the build directory or the source directory?
what kind of artifact is it? how to address $(srcdir) vs $(src) in
that context? bla bla") that really over complicate things.

Jason

Re: .S_shipped unnecessary?

[Masahiro Yamada]

On Fri, Nov 9, 2018 at 8:42 AM Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>
> (+ Masahiro, kbuild ml)
>
> On 8 November 2018 at 21:37, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> > Hi Ard, Eric, and others,
> >
> > As promised, the next Zinc patchset will have less generated code! After a
> > bit of work with Andy and Samuel, I'll be bundling the perlasm.
> >
>
> Wonderful! Any problems doing that for x86_64 ?
>
> > One thing I'm wondering about, though, is the wisdom behind the current
> > .S_shipped pattern. Usually the _shipped is for big firmware blobs that are
> > hard (or impossible) to build independently. But in this case, the .S is
> > generated from the .pl significantly faster than gcc even compiles a basic
> > C file. And, since perl is needed to build the kernel anyway, it's not like
> > it will be impossible to find the right tools. Rather than clutter up commits
> > with the .pl _and_ the .S_shipped, what would you think if I just generated
> > the .S each time as an ordinary build artifact. AFAICT, this is fairly usual,
> > and it's hard to see downsides. Hence, why I'm writing this email: are there
> > any downsides to that?
> >
>
> I agree 100%. When I added this the first time, it was at the request
> of the ARM maintainer, who was reluctant to rely on Perl for some
> reason.
>
> Recently, we have had to add a kludge to prevent spurious rebuilds of
> the .S_shipped files as well.
>
> I'd be perfectly happy to get rid of this entirely, and always
> generate the .S from the .pl, which to me is kind of the point of
> carrying these files in the first place.
>
> Masahiro: do you see any problems with this?


No problem.


Documentation/process/changes.rst says the following:

You will need perl 5 and the following modules: ``Getopt::Long``,
``Getopt::Std``, ``File::Basename``, and ``File::Find`` to build the kernel.



We can assume perl is installed on the user's build machine.



--
Best Regards
Masahiro Yamada