Re: .S_shipped unnecessary?
On Fri, Nov 9, 2018 at 8:42 AM Ard Biesheuvel wrote: > > (+ Masahiro, kbuild ml) > > On 8 November 2018 at 21:37, Jason A. Donenfeld 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
Re: .S_shipped unnecessary?
Hey Ard,
On Fri, Nov 9, 2018 at 12:42 AM Ard Biesheuvel
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, kbuild ml) On 8 November 2018 at 21:37, Jason A. Donenfeld 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?
